一、設計階段流程

1. 規劃階段：主要工作是對資料庫的必要性和可行性進行分析。確定是否需要使用資料庫，使用哪種型別的資料庫，使用哪個資料庫產品。

2. 概念階段：主要工作是收集並分析需求。識別需求，主要是識別資料實體和業務規則。對於一個系統來說，資料庫的主要包括業務資料和非業務資料，而業務資料的定義，則依賴於在此階段對使用者需求的分析。需要儘量識別業務實體和業務規則，對系統的整體有初步的認識，並理解資料的流動過程。理論上，該階段將參考或產出多種文件，比如“用例圖”，“資料流圖”以及其他一些專案文件。如果能夠在該階段產出這些成果，無疑將會對後期進行莫大的幫助。

   記錄使用者需求時，可以使用一些技巧，當然這部分內容有些可能會超出資料庫設計人員的職責：

   • 努力維護一系列包含了系統設計和規格說明資訊的文件，如會議記錄、訪談記錄、關鍵使用者期望、功能規格、技術規格、測試規格等。
   • 頻繁與干係人溝通並收集反饋。
   • 標記出你自己新增的，不屬於客戶要求的，未決內容。
   • 與所有關鍵干係人儘快確認專案範圍，併力求凍結需求。

   此外，必須嚴謹處理業務規則，並詳細記錄。在之後的階段，將會根據這些業務規則進行設計。當該階段結束時，你應該能夠回答以下問題：

   • 需要哪些資料？
   • 資料該被怎樣使用？
   • 哪些規則控制著資料的使用？
   • 誰會使用何種資料？
   • 客戶想在核心功能介面或者報表上看到哪些內容？
   • 資料現在在哪裡？
   • 資料是否與其他系統有互動、整合或同步？
   • 主題資料有哪些？
   • 核心資料價值幾何，對可靠性的要求程度？

   並且得到如下資訊：

   • 實體和關係
   • 屬性和域
   • 可以在資料庫中強制執行的業務規則
   • 需要使用資料庫的業務過程
3. 邏輯階段：主要工作是繪製E-R圖，或者說是建模。主要就是識別實體關係，其次還應該考慮屬性的域（值型別、範圍、約束）。
4. 實現階段：主要針對選擇的RDBMS定義E-R圖對應的表，考慮屬性型別和範圍以及約束。
5. 物理階段：是一個驗證並調優的階段，是在實際物理裝置上部署資料庫，並進行測試和調優。

二、設計原則

1. 降低對資料庫功能的依賴：功能應該由程式實現，資料庫僅僅負責資料的儲存，以達到最低的耦合。

2. 定義實體關係的原則：
   當定義一個實體與其他實體之間的關係時，需要考量如下：

   • 牽涉到的實體 識別出關系所涉及的所有實體。
   • 所有權 考慮一個實體“擁有”另一個實體的情況。
   • 基數考量一個實體的例項和另一個實體例項關聯的數量。

   關係與表數量：

   • 描述1:1關係最少需要1張表。
   • 描述1:n關係最少需要2張表。
   • 描述n:n關係最少需要3張表。

3. 列意味著唯一的值：如果表示座標（0,0），應該使用兩列表示，而不是將“0,0”放在1個列中。

4. 列的順序：習慣上採用“主鍵 + 外來鍵 + 實體資料 + 非實體資料”這樣的順序對列進行排序顯然能得到比較好的可讀性。
5. 定義主鍵和外來鍵：資料表必須定義主鍵和外來鍵（如果有外來鍵）。在效能沒有出現問題時應該保留外來鍵，而即便效能真的出現問題，也應該對SQL文進行優化，而非放棄外來鍵約束。
6. 儘量不允許NULL：
   關於NULL我們需要了解它的幾個特性：
   
   • 任何值和NULL拼接後都為NULL。
   • 所有與NULL進行的數學操作都返回NULL。
   • 所有使用NULL值的情況，都可以通過一個有意義的值的表示，這樣有利於程式碼的可讀性和可維護性，並能從約束上增強業務資料的規範性。
   • NULL值到非NULL的更新無法做到原地更新，更容易發生索引分裂，從而影響效能。
   • NULL值在timestamp型別下容易出問題，特別是沒有啟用引數explicit_defaults_for_timestamp。
   • NOT IN、!= 等負向條件查詢在有 NULL 值的情況下返回永遠為空結果，查詢容易出錯。
   • Null 列需要更多的儲存空間：需要一個額外位元組作為判斷是否為 NULL 的標誌位。

7. 規範化—正規化：正規化將幫助我們來保證資料的有效性和完整性。

   • 目的：
     
     • 消滅重複資料。
     • 避免編寫不必要的，用來使重複資料同步的程式碼。
     • 保持表的瘦身，以及減從一張表中讀取資料時需要進行的讀運算元量。
     • 最大化聚集索引的使用，從而可以進行更優化的資料訪問和聯結。
     • 減少每張表使用的索引數量，因為維護索引的成本很高。
   • 推薦做法：
     
     • 儘可能地遵守上述規範化原則。
     • 所有屬性描述的都應該是體現被建模實體的本質的內容。
     • 至少必須有一個鍵，它唯一地標識和描述了所建實體的本質。
     • 主鍵要謹慎選擇。
     • 在邏輯階段能做多少規範化就做多少（效能不是邏輯階段考慮的範疇）。

8. 選擇資料型別：型別選擇的最基本規則是選擇滿足需要的最輕的型別，因為這樣查詢更快。

四、命名規則

1. 表：“模組名_表名”。表名最好不要用複數，原因是在使用ORM框架開發時，程式碼生成器根據DB生成類定義，表生成了某個例項的型別定義，而不是例項集合。表名不要太長。
2. 欄位：bool型別用“Is”、“Can”、“Has”等表示；日期型別命名必須包含“Date”；時間型別必須包含“Time”。
3. 儲存過程：使用“proc_”字首。
4. 檢視：使用“view_”字首。
5. 觸發器：使用“trig_”字首。