一、設計階段流程
規劃階段：主要工作是對資料庫的必要性和可行性進行分析。確定是否需要使用資料庫，使用哪種型別的資料庫，使用哪個資料庫產品。
概念階段：主要工作是收集並分析需求。識別需求，主要是識別資料實體和業務規則。對於乙個系統來說，資料庫的主要包括業務資料和非業務資料，而業務資料的定義，則依賴於在此階段對使用者需求的分析。需要盡量識別業務實體和業務規則，對系統的整體有初步的認識，並理解資料的流動過程。理論上，該階段將參考或產出多種文件，比如「用例圖」，「資料流圖」以及其他一些專案文件。如果能夠在該階段產出這些成果，無疑將會對後期進行莫大的幫助。
記錄使用者需求時，可以使用一些技巧，當然這部分內容有些可能會超出資料庫設計人員的職責：
此外，必須嚴謹處理業務規則，並詳細記錄。在之後的階段，將會根據這些業務規則進行設計。當該階段結束時，你應該能夠回答以下問題：
並且得到如下資訊：
邏輯階段：主要工作是繪製e-r圖，或者說是建模。主要就是識別實體關係，其次還應該考慮屬性的域（值型別、範圍、約束）。
實現階段：主要針對選擇的rdbms定義e-r圖對應的表，考慮屬性型別和範圍以及約束。
物理階段：是乙個驗證並調優的階段，是在實際物理裝置上部署資料庫，並進行測試和調優。
二、設計原則
降低對資料庫功能的依賴：功能應該由程式實現，資料庫僅僅負責資料的儲存，以達到最低的耦合。
定義實體關係的原則：
當定義乙個實體與其他實體之間的關係時，需要考量如下：
關係與表數量：
列意味著唯一的值：如果表示座標（0,0），應該使用兩列表示，而不是將「0,0」放在1個列中。
列的順序：習慣上採用「主鍵 + 外來鍵 + 實體資料 + 非實體資料」這樣的順序對列進行排序顯然能得到比較好的可讀性。
定義主鍵和外來鍵：資料表必須定義主鍵和外來鍵（如果有外來鍵）。在效能沒有出現問題時應該保留外來鍵，而即便效能真的出現問題，也應該對sql文進行優化，而非放棄外來鍵約束。
盡量不允許null：
關於null我們需要了解它的幾個特性：
規範化—正規化：正規化將幫助我們來保證資料的有效性和完整性。
所有屬性描述的都應該是體現被建模實體的本質的內容。
至少必須有乙個鍵，它唯一地標識和描述了所建實體的本質。
主鍵要謹慎選擇。
在邏輯階段能做多少規範化就做多少（效能不是邏輯階段考慮的範疇）。
選擇資料型別：型別選擇的最基本規則是選擇滿足需要的最輕的型別，因為這樣查詢更快。
四、命名規則
表：「模組名_表名」。表名最好不要用複數，原因是在使用orm框架開發時，**生成器根據db生成類定義，表生成了某個例項的型別定義，而不是例項集合。表名不要太長。
字段：bool型別用「is」、「can」、「has」等表示；日期型別命名必須包含「date」；時間型別必須包含「time」。
儲存過程：使用「proc_」字首。
檢視：使用「view_」字首。
觸發器：使用「trig_」字首。
關係型資料庫設計
1.五級正規化 一般滿足 即可 第一正規化的定義 如果乙個表中沒有重複組 即行與列的交叉點上只有乙個值，而不是一組值，例如 姓名 性別 字段，但 愛好 欄位不符合1nf 且定義了關鍵字 所有非關鍵屬性都依賴於關鍵字，則這個表屬於第一正規化 常記成1nf 第二正規化的定義 如果乙個表屬於1nf，且不包...
關係型資料庫 非關係型資料庫
關係型資料庫，是指採用了關係模型來組織資料的資料庫。關係模型是在1970年由ibm的研究員e.f.codd博士首先提出的，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成為主流資料庫結構的主流模型。簡單來說，關係模型指的就是二維 模型，而乙個關係型資料庫就是由二維表及其之間的聯絡所組成的乙個...
關係型資料庫 非關係型資料庫
2019 02 25 20 38 36 關係型資料庫和非關係型資料的比較 一 關係型資料庫 關係型資料庫最典型的資料結構是表，由二維表及其之間的聯絡所組成的乙個資料組織 優點 1 易於維護 都是使用表結構，格式一致 2 使用方便 sql語言通用，可用於複雜查詢 3 複雜操作 支援sql，可用於乙個表...