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

第一章：需求分析

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. 邏輯刪除標記

樂觀鎖：

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

悲觀鎖：

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

數據庫設計那些事