第一章：需求分析

1-1 數據庫設計簡介

什麽是數據庫設計？
簡單來說，數據庫設計就是根據業務系統的具體需要，結合我們所選用的數據庫管理系統，為這個系統構造出最優的數據存儲模型。並建立好數據庫中的表結構及表與表之間的關聯關系的過程。使之能有效的對應用系統中的數據進行存儲，並可以高效對已經存儲的數據進行訪問。
常用的有關系型數據庫有：mysql、sqlserver、oracle、pgsql
nosql：redis、mangodb、等等

為什麽要進行數據庫設計？
數據存儲，高效訪問

優良的設計：
減少數據冗余、避免數據維護異常、節約存儲空間、高效訪問

糟糕的設計：
存在大量冗余、存在數據插入、更新、刪除異常、浪費大量存儲空間、訪問數據低效

1-2 數據庫設計的步驟

為什麽要進行數據庫設計？
需求分析 - 邏輯設計 - 物理設計 - 維護優化

數據庫需求的作用點：

1. 數據是什麽？
2. 數據有哪些屬性
3. 數據和屬性各自的特點有哪些？

邏輯設計：
使用er圖對數據庫進行邏輯建模

物理設計：
根據數據庫的自身特點將邏輯模型轉換為物理模型

維護優化：

1. 新的需求進行建表（接到新的需求的時候，也要參照這些流程）
2. 索引優化
3. 大表拆分

1-3 需求分析的重要性簡介

為什麽要進行需求分析？
1. 了解系統中所要存儲的數據
2. 了解數據的存儲特點：時效性，不具有時效性（過期、清理、歸檔）
3. 了解數據的生命周期：快，數據量很大，但不是核心數據
4. 日誌不適合存在數據庫中。但是一定要存的話，要提前定義好清理和歸檔規則。隨著上線進行歸檔和清理。

需求分析最好是在頭腦風暴中進行碰撞然後確定下來的東西。

需求分析主要討論目標

1. 了解系統中所有存儲的數據
   1. 實體及實體之間的關系（1對1，1對多，多對多）
   2. 實體所包含的屬性有什麽？
   3. 哪些屬性和屬性的組合可以唯一標識一個實體
2. 了解數據的存儲特點
3. 了解數據的生命周期

第二章 邏輯設計

2-1 ER圖

將需求轉換為數據庫的邏輯模型
通過ER圖的形式對邏輯模型進行展示
通所選用的數據庫沒關系
名詞解釋：
關系：一個關系對應通常所說的一張表
元組：表中的一行即為一個元組
屬性：一列就是一個屬性
候選碼：表中的某個屬性組
主碼：一個關系中有多個候選碼，選定其中一個做為主碼
域: 屬性的取值範圍【男，女】
分量：元組中的一個屬性值，男和女
矩形：表示實體集，矩形內寫實體集的名字
菱形：表示聯系集（將原先多對多的關系，轉換為一對多的關系）
橢圓：表示實體的屬性，加下標的就是主鍵
線段：將屬性連接到實體集，或將實體集連接到聯系集

2-2 設計範式概要

操作異常：
插入異常：如果實體隨著另一個實體的存在而存在，既缺少某個實體時無法表示這個實體，這個表就存在插入異常
更新異常：如果更改表所對應的某個實體實例的單獨屬性時，需要將多行進行更新，那麽久說這個表存在更新異常
刪除異常：如果刪除表的某一行來反映實例失效時導致拎一個不同實例信息丟失，那麽這個表中就存在刪除異常
數據冗余：相同的數據在多個地方存在，或者說表中的某個列能夠由其他列計算得到，這樣就存在數據冗余
數據庫設計一般遵循的範式：第一範式、第二範式、第三範式、Dc範式、反範式設計、第四範式和第五範式一般不涉及。
插入異常、刪除異常、更新異常、數據冗余（一般設計，是在反範式設計中為了提高性能，以及查詢的方便程度來確認的）
一般互聯網應用查詢和更新的比例是4筆1或者3比1

2-3 第一範式

所有字段都是單一屬性，不可再分，這個單一屬性是由基本的數據類型所構成的

2-4 第二範式

定義：數據庫中表不存在非關鍵字對於候選關鍵字的部分函數依賴
對於單主鍵一定符合第二範式

2-5 第三範式

不存在非關鍵字段對任意候選字段的傳遞函數依賴則符合第三範式
第一第二第三範式都是實體設計不合理，冗余數據，傳遞主鍵依賴，導致插入修改刪除的異常。

2-6 BC範式

表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴，則符合bc範式。
候選關鍵字的傳遞函數依賴。a 決定b b 決定a 但是都是候選關鍵字。
設計的時候最好都是單關鍵字的表，組合主鍵的最好少建立。

第三章 物理設計

3-1 數據庫物理設計要做什麽

1. 選擇合適的數據庫管理系統
2. 定義數據庫、表及字段命名規範（按照數據庫定義）
3. 對所選的dbms系統選擇合適的字段類型：字段類型
4. 反範式化的設計，以空間換時間

3-2 選擇哪種數據庫

1. oracle（適合大的事務操作）
2. sqlserver（操作系統）開發語言使用的語言.net
3. mysql應用的場景
4. pgsql

3-3 MYSQL常用存儲引擎

一般現在都是默認innodb，支持事務、行級表鎖定，ndb cluster（是內存形式的，一般都不用）
archive使用場景適合日誌

3-4 數據庫表及字段類型選擇原則

表及字段的命名規範：

1. 可讀性原則，使用大小寫來格式化數據庫名來獲得良好的可讀性
2. 表意性原則
3. 長名性原則

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

生日：char、varchar、日期時間、Int時間戳
字段選擇原則：優先選擇數字類型、再次選擇date類型、其次是char、最後才是varchar

以上選擇原則：

1. 對數據進行比較（查詢條件、join條件以及排序）操作時候：同樣的數據字符處理往往比數字處理慢。
2. 數據庫中數據處理以頁為單位，列的長度越小，利於性能提升，io性能提高。數據庫最大是磁盤io的瓶頸

3-6 數據庫如何具體選字段類型

同類型：占用空間小的。整形優先
char還是varchar來存儲？

1. 如果列中藥存儲的數據長度是差不多一致的，應該考慮使用char
2. 如果列中最大數據長度小於50byte，則一般也考慮使用char
3. 一般不定義大於50byte的char類型列（不同類型的占用是不相同的，utf8是三個字節的）

decimal與float如何選擇

1. decimal用於存儲精確數據，而float只能存儲非精確數據。故精確數據只能選擇decimal類型
2. 由於float存儲空間開銷一般比decimal小，精確到7位小數只需要4個字節，15為需要8個字節。故非精確數據優先選擇float類型

時間類型如何存儲

1. 使用int來存儲時間字段（經常用的話還是使用date類型來存儲）
   優點：字段小
   缺點：使用不方便，要進行函數轉換
   限制：只能存儲到2038-1-19
2. 需要存儲時間粒度問題

3-7 數據庫設計其他註意事項

如何選擇主鍵

1. 區分業務主鍵和數據庫主鍵
   業務主鍵用於標識業務數據，進行表與表之間的關聯
   數據庫主鍵為了優化數據存儲，生成6字節的隱含主鍵
2. 根據數據庫的類型，考慮主鍵是否要順序增長
3. 主鍵的字段類型所占用的空間要近可能的小（io性能）
   避免使用外鍵約束
4. 降低數據導入的效率
5. 增加維護成本
6. 雖然不建議使用外鍵約束，但是相關聯的列上一定要建立索引。
   避免使用觸發器
7. 降低數據導入的效率
8. 可能出現意想不到的數據異常
9. 是業務邏輯變復雜
   關於預留字段
10. 無法知道預留字段的類型
11. 無法準確知道預留字段中所存儲的內容
12. 後期維護預留字段所要的成本通增加一個字段所需的成本是相同的
13. 禁止使用預留字段

3-8 反範式化表設計

為了性能和讀取效率對於第三範式進行違反，允許少量的數據冗余，提高讀取效率。換句話說就是以空間換時間。

1. 減少表關聯的數量
2. 增加數據的讀取效率
3. 反範式化一定要適度（是可控的）

第4章 維護優化

4-1 數據庫維護和優化要做什麽

1. 維護數據字段
2. 維護索引
3. 維護表結構
4. 在適當的時候對表進行水平拆分和垂直拆分

4-2 數據庫如何維護數據字典

1. 使用第三方工具對於數據字典進行維護
2. 使用數據庫本身的備註字段來維護數據字典
3. 導出數據字典，使用mysql內置表的形式

4-3 數據庫如何維護索引

如何維護索引

1. 出現在where從句，group by從句、orderby 從句
2. 選擇可選擇性高的列要放到索引的前面
3. 索引中不要包括太長的數據類型，對於前面部分的進行索引，所以禁止全關聯查詢
   註意事項：
4. 索引並不是越多越好、過多的索引不但會降低寫的效率（維護效率），還會降低讀的效率（選擇效率）。
5. 定期維護索引碎片
6. sql語句中不要使用強制索引關鍵字

4-4 數據庫中適合的操作

表結構維護：

1. 使用在線變更表結構工具
2. 同時對數據字典進行維護
3. 控制表的寬度和大小
   數據庫中適合的操作
4. 批量操作（sql） vs 逐條操作（存儲過程）
5. 禁止使用select * 這樣的函數查詢
6. 控制使用用戶自定義函數，對索引的時候產生影響
7. 不要使用數據庫中的全文索引（需要另外建立全文索引，如果必要最好使用搜索引擎）

4-5 數據庫表的垂直和水平拆分

為了控制表的寬度，可以進行表的垂直拆分：大表拆分小表（數據量是沒有變化的）

1. 經常查詢的列放到一起
2. text，blob等大字段拆分出到附加表中（優化io效率）
   為了控制表的大小可以進行表的水平拆分：
3. 通過主鍵hash的方式進行水平拆分，將五張表成為一張大表（優化表io）
   分庫
   一個數據庫已經沒有辦法將數據全部容納下的時候，就需要使用。

數據庫表設計要求

必須要有的字段：1. Id、2. 創建時間、3. 修改時間、4. 版本號、5. 邏輯刪除標記

樂觀鎖：

對更新比較信任，一般不會出現同時更新的情況
同時讀取到舊數據，同時對於數據進行更新

悲觀鎖：

對更新不信任，在進行更新的時候，會將表數據鎖住，不允許讀取，等到更新完畢後，在放開當前的鎖。
能夠保證在更新的時候，系統數據都是正確的。
要求改前將數據鎖住，別人都不能夠讀取，將數據進行修改，提交後釋放鎖，別人才能夠讀取。

數據庫設計那些事

【學習筆記】數據庫設計那些事