此筆記為尚硅谷MySQL高級篇部分內容
目錄
一、為什么要數(shù)據(jù)庫設計?
二、范式
1、范式簡介
2、范式都包括哪些?
3、鍵和相關屬性的概念
4、第一范式(1st NF)
5、第二范式(2nd NF)
6、第三范式(3rd NF)
7、小結
三、反范式化
1、概述
2、?應用舉例
3、反范式的新問題
4、反范式的適用場景?
1. 增加冗余字段的建議?
2. 歷史快照、歷史數(shù)據(jù)的需要
五、BCNF(巴斯范式)
六、第四范式（了解）
七、第五范式、域鍵范式（了解）
八、ER模型
1、ER模型包括哪些要素?
2、關系的類型?
九、數(shù)據(jù)表的設計原則?
十、數(shù)據(jù)庫對象編寫建議
1、關于庫?
2、關于表、列
3、關于索引
4、SQL編寫
一、為什么要數(shù)據(jù)庫設計?
二、范式
1、范式簡介
在關系型數(shù)據(jù)庫中，關于數(shù)據(jù)表設計的基本原則、規(guī)則就稱為范式。可以理解為，一張數(shù)據(jù)表的設計結構需要滿足的某種設計標準的 級別 。要想設計一個結構合理的關系型數(shù)據(jù)庫，必須滿足一定的范式。
2、范式都包括哪些?
目前關系型數(shù)據(jù)庫有六種常見范式，按照范式級別，從低到高分別是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又稱完美范式）。
3、鍵和相關屬性的概念
范式的定義會使用到主鍵和候選鍵，數(shù)據(jù)庫中的鍵(Key)由一個或者多個屬性組成。數(shù)據(jù)表中常用的幾種鍵和屬性的定義:
超鍵︰能唯─標識元組的屬性集叫做超鍵。
候選鍵︰如果超鍵不包括多余的屬性，那么這個超鍵就是候選鍵?！ぶ麈I:用戶可以從候選鍵中選擇一個作為主鍵。
外鍵∶如果數(shù)據(jù)表R1中的某屬性集不是R1的主鍵，而是另一個數(shù)據(jù)表R2的主鍵，那么這個屬性集就是數(shù)據(jù)表R1的外鍵。
主屬性:包含在任一候選鍵中的屬性稱為主屬性。
非主屬性:與主屬性相對，指的是不包含在任何一個候選鍵中的屬性。通常，我們也將候選鍵稱之為“
碼”，把主鍵也稱為“主碼”。因為鍵可能是由多個屬性組成的，針對單個屬性，我們還可以用主屬性和非主屬性來進行區(qū)分
4、第一范式(1st NF)
第一范式主要是確保數(shù)據(jù)表中每個字段的值必須具有
原子性，也就是說數(shù)據(jù)表中每個字段的值為不可再次拆分的最小數(shù)據(jù)單元。
5、第二范式(2nd NF)
第二范式要求，在滿足第一范式的基礎上，還要滿足數(shù)據(jù)表里的每一條數(shù)據(jù)記錄，都是可唯一標識的。而且所有非主鍵字段，都必須完全依賴主鍵，不能只依賴主鍵的一部分。如果知道主鍵的所有屬性的值，就可以檢索到任何元組(行)的任何屬性的任何值。(要求中的主鍵，其實可以拓展替換為候選鍵)。
6、第三范式(3rd NF)
第三范式是在第二范式的基礎上，確保數(shù)據(jù)表中的每一個非主鍵字段都和主鍵字段直接相關，也就是說，要求數(shù) 據(jù)表中的所有非主鍵字段不能依賴于其他非主鍵字段。(即，不能存在非主屬性A依賴于非王屬性B，非士屬任B依賴于主鍵C的情況，即存在“A→B一C”"的決定關系）通俗地講，該規(guī)則的意思是所有
非主鍵屬性之間不能有依 賴關系，必須相互獨立。這里的主鍵可以拓展為候選鍵。
7、小結
關于數(shù)據(jù)表的設計，有三個范式要遵循。
(1）第一范式(1NF)，確保每列保持
原子性數(shù)據(jù)庫的每一列都是不可分割的原子數(shù)據(jù)項，不可再分的最小數(shù)據(jù)單元，而不能是集合、數(shù)組、記錄等非原子數(shù)據(jù)項。
(2）第二范式(2NF)，確保每列都和主鍵
完全依賴尤其在復合主鍵的情況下，非主鍵部分不應該依賴于部分主鍵。
(3）第三范式(3NF）確保每列都和主鍵列
直接相關，而不是間接相關
范式的優(yōu)點: 數(shù)據(jù)的標準化有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余，第三范式(3NF）通常被認為在性能、擴展性和數(shù)據(jù)完整性方面達到了最好的平衡。
范式的缺點: 范式的使用，可能降低查詢的效率。因為范式等級越高，設計出來的數(shù)據(jù)表就越多、越精細，數(shù)據(jù)的冗余度就越低，進行數(shù)據(jù)查詢的時候就可能需要關聯(lián)多張表，這不但代價昂貴，也可能使一些索引策略無效。
范式只是提出了設計的標準，實際上設計數(shù)據(jù)表時，未必一定要符合這些標準。開發(fā)中，我們會出現(xiàn)為了性能和讀取效率違反范式化的原則，通過增加少量的冗余或重復的數(shù)據(jù)來提高數(shù)據(jù)庫的讀性能，減少關聯(lián)查詢,join表的次數(shù)，實現(xiàn)空間換取時間的目的。因此在實際的設計過程中要理論結合實際，靈活運用。
范式本身沒有優(yōu)劣之分，只有適用場景不同。沒有完美的設計，只有合適的設計，我們在數(shù)據(jù)表的設計中，還需要根據(jù)需求將范式和反范式混合使用。
三、反范式化
1、概述
規(guī)范化 vs 性能
- 1. 為滿足某種商業(yè)目標 , 數(shù)據(jù)庫性能比規(guī)范化數(shù)據(jù)庫更重要
- 2. 在數(shù)據(jù)規(guī)范化的同時 , 要綜合考慮數(shù)據(jù)庫的性能
- 3. 通過在給定的表中添加額外的字段，以大量減少需要從中搜索信息所需的時間
- 4. 通過在給定的表中插入計算列，以方便查詢
2、?應用舉例
3、反范式的新問題
- 存儲 空間變大 了
- 一個表中字段做了修改，另一個表中冗余的字段也需要做同步修改，否則 數(shù)據(jù)不一致
- 若采用存儲過程來支持數(shù)據(jù)的更新、刪除等額外操作，如果更新頻繁，會非常 消耗系統(tǒng)資源
- 在 數(shù)據(jù)量小 的情況下，反范式不能體現(xiàn)性能的優(yōu)勢，可能還會讓數(shù)據(jù)庫的設計更加 復雜
4、反范式的適用場景?
當冗余信息有價值或者能 大幅度提高查詢效率 的時候，我們才會采取反范式的優(yōu)化。
1. 增加冗余字段的建議?
2. 歷史快照、歷史數(shù)據(jù)的需要
在現(xiàn)實生活中，我們經常需要一些冗余信息，比如訂單中的收貨人信息，包括姓名、電話和地址等。每次發(fā)生的 訂單收貨信息 都屬于 歷史快照 ，需要進行保存，但用戶可以隨時修改自己的信息，這時保存這些冗余信息是非常有必要的。
反范式優(yōu)化也常用在 數(shù)據(jù)倉庫 的設計中，因為數(shù)據(jù)倉庫通常 存儲歷史數(shù)據(jù) ，對增刪改的實時性要求不強，對歷史數(shù)據(jù)的分析需求強。這時適當允許數(shù)據(jù)的冗余度，更方便進行數(shù)據(jù)分析。
五、BCNF(巴斯范式)
六、第四范式（了解）
七、第五范式、域鍵范式（了解）
八、ER模型
1、ER模型包括哪些要素?
ER 模型中有三個要素，分別是實體、屬性和關系。
- 實體 ，可以看做是數(shù)據(jù)對象，往往對應于現(xiàn)實生活中的真實存在的個體。在 ER 模型中，用 矩形 來表示。實體分為兩類，分別是 強實體 和 弱實體 。強實體是指不依賴于其他實體的實體；弱實體是指對另一個實體有很強的依賴關系的實體。
- 屬性 ，則是指實體的特性。比如超市的地址、聯(lián)系電話、員工數(shù)等。在 ER 模型中用 橢圓形 來表示。
- 關系 ，則是指實體之間的聯(lián)系。比如超市把商品賣給顧客，就是一種超市與顧客之間的聯(lián)系。在 ER 模型中用 菱形 來表示。
注意：實體和屬性不容易區(qū)分。這里提供一個原則：我們要從系統(tǒng)整體的角度出發(fā)去看，可以獨立存在的是實體，不可再分的是屬性。也就是說，屬性不能包含其他屬性。?
2、關系的類型?
九、數(shù)據(jù)表的設計原則?
綜合以上內容，總結出數(shù)據(jù)表設計的一般原則："三少一多"
- 1. 數(shù)據(jù)表的個數(shù)越少越好
- 2. 數(shù)據(jù)表中的字段個數(shù)越少越好
- 3. 數(shù)據(jù)表中聯(lián)合主鍵的字段個數(shù)越少越好
- 4. 使用主鍵和外鍵越多越好
注意：這個原則并不是絕對的，有時候我們需要犧牲數(shù)據(jù)的冗余度來換取數(shù)據(jù)處理的效率。?
十、數(shù)據(jù)庫對象編寫建議
1、關于庫?
2、關于表、列
3、關于索引
4、SQL編寫
高級篇筆記PDF自取文章來源：http://www.zghlxwxcb.cn/news/detail-478553.html
鏈接：https://pan.baidu.com/s/1pVqrTwIZFoED77i-EFmw6g?pwd=3333?
提取碼：3333文章來源地址http://www.zghlxwxcb.cn/news/detail-478553.html
到了這里，關于【MySQL高級篇筆記-數(shù)據(jù)庫的設計規(guī)范(中) 】的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
