一、系統需求分析階段

數據庫設計的第一步，就是了解與分析用戶需求，確定系統邊界信息需求、處理需求、安全性和完整性需求，然后編寫系統分析報告。

系統分析報告的內容主要包括：

隨系統分析報告需提供的附件還有：

需求分析有兩種方法：自頂向下和自底向上。

具體來說，自底向上的分析，是從具體到抽象；而自頂向下的分析，則是從抽象到具體。舉個例子就比較好理解了：

比如你想搭建一個電子商務網站，如果你是先確定核心模塊包括哪些，然后根據每子模塊的屬性繼續往下分。那么這種就是自頂而下的分析。

反之，如果你是先整理出大量的屬性，然后對這些屬性進行歸納總結出幾大模塊，那么就是自底向上的分析。

二、概念結構設計階段

概念結構設計，就是將上一階段通過需求分析得到的用戶需求抽象為概念結構，或稱為概念模型（整個過程，其實就是我們前面提到的自底向上的分析）。描述概念模型的有力工具是E-R模型。

E-R模型由三大要素組成，分別是實體、屬性和聯系。

• 實體是一個數據的使用者，代表軟件系統中客觀存在的生活中的實物，比如物體、人、部門、項目等；
• 實體中的所有特性稱為屬性，如用戶有特定的姓名、性別、住址、電話、郵箱等元素；
• 實體與實體間存在聯系，如，某一個人在某個公司的某個部門工作，其中的實體有"某個人"、“某個公司”和"某個公司的某個部門"。

E-R模型的繪制需要遵循三范式原則：

三、邏輯結構設計階段

數據庫邏輯設計，則是將上一階段的概念結構轉換成特定DBMS所支持的數據模型的過程。如下圖所示：

其中初始關系模式設計過程，就是將E-R模型向關系模式的轉換。

轉換中要遵循以下原則：

• 一個實體轉換為一個關系模式，實體的屬性就是關系的屬性，實體的鍵就是關系的鍵；
• 具有相同主鍵的關系可以合并；
• 一個聯系轉換為一個關系模式，分為以下幾種情況：

一個1：1的聯系可以轉化為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。
一個1：N的聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。

假如有老師和學校兩個實體，一個學校可以招收多個老師，但是一個老師只能選擇一個學校（這里不討論特殊情況）， 因此學校和老師是1：N的關系。現在要轉換為關系模型，我們只需在老師的這端加上學校的唯一標識即可，這樣做的原因是，因為一個老師只能在一個學校，學校相對老師是唯一的。

一個M：N的聯系轉換為一個關系。關系的屬性由聯系本身的屬性和與之聯系的實體的主鍵組成，關系的主鍵由聯系中各實體的主鍵組合而成（組合鍵）。

四、物理結構設計階段

物理設計是為邏輯數據模型選取一個最適合應用環境的物理結構。

1.選擇哪種數據庫

商業數據庫（更適合企業級項目），比如：Oracle、SQLServer
開源數據庫（適用于互聯網項目）。比如：MySQL、PgSQL

2.數據庫表級字段的命名規則：

可讀性原則：使用大寫和小寫來格式化的庫對象名字以獲得良好的可讀性
表意性原則：對象的名字應該能夠描述它所標識的對象
長名原則：盡可能少使用或者不使用縮寫，適用于數據庫（DATABASE）名之外的任一對象

3.數據庫字段類型選擇原則

以上選擇原則主要是從下面兩個角度考慮：

1）在對數據進行比較（查詢條件、JOIN條件及排序）操作時：同樣的數據，字符處理往往比數字處理慢
2）在數據庫中，數據處理以頁為單位，列的長度越小，利于性能提升。

4.數據庫設計其它注意事項

1）區分業務主鍵和數據庫主鍵：業務主鍵用于標識業務數據，進行表與表之間的關聯；數據庫主鍵為了優化數據存儲（Innodb會生成6個字節的隱含主鍵）

2）根據數據庫的類型，考慮主鍵是否要順序增長：有些數據庫是按主鍵的順序邏輯存儲的

3）主鍵的字段類型所占空間要盡可能的小：對于使用聚集索引方式存儲的表，每個索引后都會附加主鍵信息

---

嚴格來說，數據庫設計還有后續的實施階段和運行維護階段，如果繼續展開下去又得半小時，這里就不做復述了（其實是想偷懶）。感興趣的朋友可以在我整理的數據庫資源包里找到續篇，包里還有其他數據庫相關的思維導圖學習資料，一并分享給大家。

總結

以上是生活随笔為你收集整理的详解数据库设计的四个阶段的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。