需求分析（根據資料的屬性和特點設定資料型別）；
邏輯設計（er 圖）；
物理設計（選擇開發環境）；
維護優化（新建表、索引、拆分）； 關係
乙個關係對應通常所說的一張表；
元組表中的一行為乙個元組；
屬性表中的一列為乙個屬性；每乙個屬性有乙個名稱為屬性名（表字段）；
候選碼表中的某個屬性級，它可以唯一確定乙個元組；
主碼乙個關係有多個候選碼，選定其中乙個為主碼；
域屬性的取值範圍（e.g.: 真假：y/n...）；
分量元組中的乙個屬性值；
矩形：實體集；
菱形：關係集；
橢圓：屬性；
線：關係；
合理分庫、分表。按期歸檔，使資料庫高效運轉。
資料冗餘
指相同的資料在多個地方存在（多個表存在，乙個表多個字段意義相同），或者說某個列可以由其他列計算得到，這樣就說表中存在著資料冗餘（不符合正規化要求既有資料冗餘）。
可包括——
3.2.1. 第一正規化 (1nf)定義
資料庫表中所有欄位均為
單一屬性，且
不可再分；
補充單一屬性指由基本的資料型別（如：整數、浮點數、字串等）構成；
釋義表都必須是二維表；不可表中套表；
3.2.2. 第二正規化 (2nf)定義
資料庫表中不存在非關鍵字段對任一候選關鍵字段的
部分函式依賴；
補充部分函式依賴是指存在著組合關鍵字中的某一關鍵字決定非關鍵字的情況；
釋義表都必須是單關鍵字段的表；
問題不符合 2nf 時可能產生的問題：插入異常、更新異常、刪除異常、資料冗餘；
解決拆分成單關鍵字的表（兩個表 + 乙個關係表）；
3.2.3. 第三正規化 (3nf)定義
若資料表不存在非關鍵字段、也不存在對任意候選關鍵字段的
傳遞函式依賴 則符合 3nf；
釋義不存在非主屬性部分函式依賴於碼，同時不傳遞依賴與碼；
問題不符合 3nf 時可能產生的問題：插入異常、更新異常、刪除異常、資料冗餘；
解決拆分成單關鍵字的表（兩個表 + 乙個關係表）；
3.2.4. bc 正規化 (bcnf)定義
在 3nf 基礎上，若不存在任何欄位對任一候選關鍵字段的傳遞函式依賴則符合 bcnf；
釋義若有復合關鍵字，則復合關鍵字之間不能存在函式依賴關係（不可一詞多義）；
3.2.5. 第四正規化
暫無簡介
3.2.6. 第五正規化
暫無簡介
選擇合適的資料庫管理系統：
a. 商業資料庫（企業級專案）：oracle、sql server；
b. 開源資料庫（網際網路專案）：mysql、pgsql；
設定資料庫表及字段命名、資料庫設計規範；
由所選 dbms 選用合適的資料型別；
反正規化設計：過分要求正規化設計必定會增加關係度的複雜，應在正規化與簡約節時的原則上找到平衡；4.2. mysql 初步
4.2.1. 儲存引擎
大多數網際網路應用建議使用 innodb；
4.2.2. 命名規範
4.2.3. 字段型別選用
資料查詢效能：對資料進行比較（查詢條件、join 條件及排序分組等）操作時，同樣的資料，數字比字元處理要快；
儲存空間開銷：在資料庫中，資料處理以頁為單位，列的長度越小，位元組越小，利於 i/o 效能提公升（單頁 sql server: 8k、mysql: 16k）；
資料型別優先順序：數字>日期=二進位制型別>字元型別；相同級別的資料型別，優先選擇占用空間小的資料型別；
4.2.4. 字元：char/varchar
如果列中要儲存的資料長度差不多一致，則使用char；否則考慮varchar（e.g.: 手機號/身份證號碼）；
如果列中的最大資料長度小於 50 byte，一般考慮用char（如果這個列很少用，則基於節省空間和減少 i/o 的考慮，也可以用varchar）；
一般不宜定義大於 50 byte 的char型別列；
4.2.5. 數字：decimal/float
decimal用於儲存精確資料，而float只能用於儲存非精度資料；
由於float的儲存空間開銷一般比demimal小；故非精度資料優先選擇float；
int：字段長度比datetime小；使用不方便，要進行函式轉換，且只能儲存到 2038-01-19 11:14:07；使用、查詢少宜用int；
datetime：查詢頻繁的時間戳；
需要儲存的時間粒度：年月日時分秒周；
4.2.7. 其它字元
計算機中使用的文字和符號；
位元組計量單位；
ascii 編碼中，乙個英文本母（不分大小寫）佔乙個位元組的空間，乙個中文漢字佔兩個位元組的空間。乙個二進位制數字序列，在計算機中作為乙個數字單元，一般為 8 位二進位制數，換算為十進位制。最小值 0，最大值 255。4.2.8. 主鍵選用utf-8 編碼中，乙個英文本元等於乙個位元組，乙個中文（含繁體）等於三個位元組。
unicode 編碼中，乙個英文等於兩個位元組，乙個中文（含繁體）等於兩個位元組。符號：英文標點佔乙個位元組，中文標點佔兩個位元組。舉例：英文句號「.」佔 1 個位元組的大小，中文句號「。」佔 2 個位元組的大小。
utf-16 編碼中，乙個英文本母字元或乙個漢字字元儲存都需要 2 個位元組（unicode 擴充套件區的一些漢字儲存需要4個位元組）。
utf-32 編碼中，世界上任何字元的儲存都需要 4 個位元組。
選擇原則
避免使用外來鍵約束
避免使用觸發器
關於預留字段
4.2.9. 反正規化化設計
為了效能和讀取效率的考慮而適當的對第三正規化的要求進行違反，允許存在少量的資料冗餘；即以空間換時間。
維護索引
注意事項
同時對資料字典進行維護；
控制表的寬度和大小（表字段的大小控制，表資料量的分割槽，拆分處理等）；
適合的操作
批量操作和逐條操作；
禁止使用select *這樣的查詢（把不必要的字段也查詢出來，浪費 i/o）；
控制使用使用者自定義函式（索引失效）；
不要使用資料庫中的全文索引；
水平拆分
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...