前段時間自己嘗試做了一個app，對於數據庫設計方面稍有學習。在這裏進行總結，以備後期更改和查閱。
一：數據庫設計的重要性
隨着業務的開展，數據庫中的數據會非常龐大。如果數據庫設計良好，比如選擇合適的數據類型，他會極大的減小數據存儲的空間。同時良好的範式標準也可以避免數據維護異常（增刪改查）。同時合理的違反範式規則有助於高效的數據庫訪問。
同時項目之後的拓展，數據庫也不會出現大改的情況。
二：數據庫設計的步驟
1:需求分析
2:邏輯設計
3:物理設計
4:維護和優化
三：需求分析
在這一步要明白數據是什麼，數據有哪些屬性，以及數據和屬性的各自特點是什麼。
將所需要的功能模塊都列出來了，將每一個獨立的實體對象（一般是名詞）劃分爲單獨的模塊，例如用戶模塊。需要將這個模塊中的涉及的屬性列舉出來，並選擇可選唯一標識屬性，最後確定他數據的存儲特點。
就拿用戶模塊舉個例子：
1屬性：用戶ID，用戶名，球衣號碼，球員頭像，個性簽名，郵箱，密碼
2可選唯一標識屬性：用戶ID，郵箱
3存儲特點：隨着系統上線的時間，業務的拓展，模塊中的數據會越來越多，而且用戶模塊中的數據不需要做數據刪除歸檔存儲，需要進行永久存儲。
存儲特點：
確定存儲規則的前提就是需要明白數據的
1）：對於一些重要數據，例如用戶模塊：是進行永久存儲的不建議進行數據刪除和歸檔存儲。
2）：對於一些過期的信息，例如商城軟件的下線商品，可以進行歸檔處理（歸檔存儲），遷移到別的表中，而且也不能進行刪除這些商品，因爲有些訂單是和他們相關聯的。
通過遷移歸檔，來保持商品表的小數量級。
3）：對於一些用戶隨時調用的數據，需要永久存儲不能刪除，但是隨着業務的開展，數據量會越來越大，此時需要進行分表分庫存儲。
其他還有很多定義的存儲規則，但目前還是初始入門，先列出上述。
四：邏輯設計
邏輯設計的主要目的是將需求轉化爲數據庫的邏輯模型，可以簡單的理解爲將一個抽象的文字描述，轉換爲一個更具體的關係模型。
在邏輯設計中ER圖就是邏輯設計的展示形式。
基本概念
1關係：每一個就是一個關係，一個關係就是對應一個表
2元組：表中的一行就是一個元組，更現實一點就是需求分析中的每一個實體都是一個元組
3屬性：表中的每一列都是一個屬性
4候選碼：表中的一個屬性或者是一組屬性他可以唯一確定一個元組，那麼這個屬性或者一組屬性被稱爲候選碼。
5主碼：從候選碼裏選擇出一個作爲主碼
6作用域：屬性的取值範圍
7分量：即元組中的一個屬性值，並要求不可再分。例如分組中的一個屬性爲工資，但他的屬性值有基本工資和加班工資等多種，此時的數據庫設計就是不合格的
8矩形：表示實體集例如用戶，場地
9菱形：菱形表示關係集，也就是實體之間的關係，他的重要作用就是將多對多的關係轉換成1對多的關係
10橢圓：表示實體的屬性
11線段：將屬性連接到實體集或者將實體集連接到關係集
在關係型數據庫中，關係是要滿足不同程度要求的，而這不同程度的要求就是不同的範式，範式越高規範化程度就越高。而符合規範的設計可以防止數據庫的CURD出現異常，也可以最大程度的防止出現數據冗餘。可以通過模式分解將低級範式關係模型轉換成高級範式關係模型，同時這個過程也被稱爲規範化。
第一範式（1NF）
第一範式的要求是數據庫中所有的字段都是單一的屬性，不可再分。例如前面所提到的工資屬性，他可以被分爲基本工資加班工資等多種子屬性，這是不被允許的，違反了第一範式。
第二範式（2NF）
1:無部分函數依賴； 2:無組合關鍵字
如一張表中有如下屬性：
- 商品名稱
- 供應商名稱
- 價格
- 重量
- 供應商電話
第二範式要求屬性完全依賴於主鍵 這一原則可以被拆分成兩部分 1:無部分函數依賴； 2:無組合關鍵字。
在這張表中有兩個關鍵字：商品名稱和供應商名稱。其中價格重量分類是依賴於主鍵商品名稱的；供應商電話是依賴於主鍵供應商名稱的。這就違背了無部分函數依賴的原則。同時商品名稱和供應商名稱組成了組合關鍵字，這就違背了無組合關鍵字的原則。
可以通過模式分解將這張表進行規範化，分成兩張數據表
表一： 商品名稱，價格，重量。
表二： 供應商名稱，供應商電話。
如果需要的話，可以增加一個關聯關係表即可。
第三範式（3NF）
一直以來，第三範式都可以被理解爲：滿足不存在傳遞函數依賴關係，其實大部分時間我開始明白了這個概念但是一段時間後還是忘記了，不夠通俗的解釋。
在前面的第二範式中學習到爲了滿足屬性完全依賴主鍵，已經將一張表中的屬性拆分成兩張數據表，在保證滿足第二範式之後纔會去考慮是否滿足第三範式。說到這裏就可以直接概括爲第三範式就是要求一個數據表中不允許包含已經在其他的表中已經包含的非主鍵屬性。例如前面符合2NF的表一如果再添加上分類和分類描述這兩個屬性就是違背了第三範式的原則。
商品名稱依賴於分類，分類依賴於分類描述
通過使用模式分解進行規範化，分解成兩張數據表和一張關係表
表一：商品表
表二：分類表
表三：商品分類關聯信息表
但有時爲了性能和讀取效率會適當的違反第三範式以空間換時間，允許存在一些冗餘
五：物理設計
在之前完成邏輯設計之後開發人員會在這一步選擇合適的數據庫管理系統，並建立數據庫的表結構，定義數據庫的表以及字段的命名規範使其不需要查詢數據字典就可以明白他的意義。並可以根據DBMS選擇合適的字段類型。以及爲了性能犧牲空間的反範式化設計。
在實際開發學習中我只初步使用過PgSQL，太深的知識並沒涉及過，水平有限在這裏就不再詳細描述了。
1:數據庫表以及字段的命名規則
1）：可讀性原則（駝峯法則）
2）：表意性原則（從命名中就可以看出意義）
2:字段類型的選擇
字段類型的選擇影響了數據存儲空間的開銷，也影響了數據查詢性能。因此字段類型的選擇是很重要的。
字段類型選擇的優先級：
1:數字類型
2:日期或者二進制類型
3:字符類型
4:相同級別的應該考慮佔用空間小的數據類型例如varchar和char
5:其他的應該根據實際要求去設定例如decimal和float
3:反範式化設計
有時用戶使用的某一處涉及到的數據庫操作會涉及到很多的表，適當的違反一下第三範式的要求可以提高查詢效率。
反範式化的設計可以減少表的關聯數量減少數據庫的輸入輸出操作從而進一步提高數據的讀取效率。
但是爲了將寫操作異常控制在可控範圍，反範式化一定要適度。
六：維護和優化
1:維護數據字典
1:用第三方工具維護數據字典
2:使用表的comment註釋表並將數據字典導出
2:維護索引
索引一般出現在where， group by， order by從句所在的列，要注意索引中不要包括太長的數據量；同時過多的索引會降低讀寫效率。
3:表結構維護
以MySQL爲例在5.5爲界限，之後版本的支持在線表結構的變更，在此之前要使用插件。
要注意控制表的寬度和大小，超出界限需要進行拆分。
4:對錶進行拆分
垂直拆分：
爲了控制表的寬度：當數據表的列太多時，需要將這些列進行拆分，此時需要將經常在一起查詢的列放在一起將text等大字段拆分到附加表中，這樣做的好處是可以不用做SQL關聯操作，優化IO，減少表的複雜程度，提高效率。
水平拆分：
爲了控制表的大小，將表的數據量進行拆分，此時每一個表的結構都是一樣的。
最後的話
上述內容是在進行個人項目之前對數據庫設計的學習總結，學習資源來源於慕課網。
對於數據庫的初次嘗試出現了很多的問題，但爲了項目的長久發展，數據庫的良好設計是非常重要的。之後瞭解深入之後會對項目的數據庫進行進一步優化。
有問題歡迎指出糾正。