1.為什么需要數據庫設計
設計數據表的時候，要考慮很多的問題:
如果數據庫設計得不合理的話，可能導致下面的幾種問題:
- 設計容易，信息重復，存儲空間浪費
- 數據更新，插入，刪除的異常
- 不能正確表示信息
- 丟失有效信息
- 程序性能差
我們可以看出設計良好的數據庫是很重要的，它有下面的優(yōu)點:
- 節(jié)省數據的存儲空間
- 能夠保證數據的完整性
- 方便進行數據庫應用系統(tǒng)的開發(fā)
- 設計數據庫，我們得重視數據表的設計，為了建立冗余度小，結構合理的數據庫，設計數據庫必須遵循一定的規(guī)則。
2.范式(Normal Formal）
2.1范式概述
關系型數據庫中，關于數據表設計的基本原則，規(guī)則就稱為范式，范式是我們在設計數據庫結構過程中需要遵循的規(guī)則和指導方法。
不過，有的時候為了提高某一些查詢性能，我們還需要破壞范式規(guī)則，也就是反規(guī)范化。
2.2鍵和相關屬性的概念
范式的定義會用到主鍵和候選鍵，我們先來看看相關的概念，數據庫中的鍵是由一個或多個屬性組成的，我們來看一下數據表中常用的幾種鍵和屬性的定義。
2.3第一范式(1NF)
- 第一范式主要是保證數據表中的每一個字段的值必須具有原子性，也就是數據表中的每個字段的值是不可再拆分的最小數據單元
- 屬性的原子性是主觀的，我們要根據實際項目的需求來設計，比如說地址，如果項目沒有說要細分為省，市，縣，鎮(zhèn)這么具體的話，我們一般就可以不拆分。
2.4第二范式(2NF）
- 第二范式要求在滿足第一范式的基礎上，還要滿足數據表里的每一條數據記錄，都是可唯一標識的，而且所有的非主鍵字段，都必須完全依賴主鍵，不能只依賴主鍵的一部分。
- 如果知道主鍵的所有屬性的值，我們就可以檢索任何元組(行)的任何屬性的任何值(要求中的主鍵可以拓展替換為候選鍵)
比如說，在成績表(學號，課程號，成績)關系中，(學號，課程號)可以決定成績，因為一個學生可以選多門課，一門課也可以被多個學生選擇，所以學號或課程號都不能單獨決定成績。
所以(學號，課程號)——>成績就是完全依賴關系。
比賽表里面包含球員編號，姓名，年齡，比賽編號，比賽實際和比賽場地等屬性，候選鍵和主鍵都是(球員編號，比賽編號),我們可以通過候選鍵(主鍵)來決定下面的關系。
(球員編號，比賽編號)——>(姓名，年齡，比賽時間，比賽場地，得分)
但是這個數據表不滿足第二范式，因為數據表中的字段之間還存在下面的對應關系:
(球員編號)——>(姓名，年齡)
(比賽編號)——>(比賽時間，比賽場地)
非主屬性并非完全依賴候選鍵，這樣會產生下面的問題。
- 數據冗余:如果一個球員參加m場比賽，那么球員的姓名和年齡就重復了m-1次，一個比賽可能有n個球員參加，比賽時間和地點就重復了n-1次
- 插入異常:如果我們要添加一場新的比賽，但是這時還沒有確定參加的球員都有誰2，那么就沒發(fā)插入
- 刪除異常:我們想刪除某個球員編號，但是如果沒有單獨保存比賽表的話，就會同時把比賽信息刪除掉
- 更新異常:如果我們調整了某個比賽時間，那么數據表所有的這個比賽的時間都得進行調整，不然就會出現同一場比賽但是時間不同的情況。
為了避免上述情況，我們可以把球員比賽表設計成下面的三張表。
這樣的話，每張數據表都符合第二范式，，就避免了異常情況的發(fā)生
第二范式要求實體的屬性完全依賴主關鍵字，如果存在不完全依賴，那么這個屬性和主關鍵字的這一部分就應該分離處理形成一個新的實體，新實體和原來實體之間是一對多的關系
2.5第三范式(3NF）
- 第三范式建立在已經滿足第二范式的基礎上
- 數據表中的每一個非主鍵字段都和主鍵字段直接相關
- 也就是說數據表中的所有非主鍵字段不能依賴于其他非主鍵字段
- 這個規(guī)則的意思是所有非主屬性之間不能有依賴關系，它們是互相獨立的
- 這里的主鍵可以拓展成為候選鍵
、
2.6范式的優(yōu)缺點
- 優(yōu)點:
- 數據的標準化有助于消除數據庫中的數據冗余
- 第三范式通常被認為在性能，擴展性和數據完整性方面達到了最好的平衡
- 缺點:
- 降低了查詢效率，因為范式等級越高，設計出來的表就越多，進行數據查詢的時候就可能需要關聯多張表，不僅代價昂貴，而且可能會使得一些索引失效
- 范式只是提出設計的標標準，實際設計的時候，我們可能為了性能和讀取效率違反范式的原則，通過增加少量的冗余或重復的數據來提高數據庫的讀取性能，減少關聯查詢，實現空間換時間的目的
3.反范式化
3.1概述
- 遵循業(yè)務優(yōu)先的原則
- 首先滿足業(yè)務需求，再進來減少冗余
- 有時候我們想要對查詢效率進行優(yōu)化，反范式化也是一種優(yōu)化思路，我們可以通過在數據表中增加冗余字段來提高數據庫的讀性能。
3.2 反范式的新問題
反范式雖然可以通過空間換實際，提升查詢的效率，但是反范式也會帶來一些新問題
- 存儲空間變大了
- 一個表中字段做了修改，另外一個表中冗余字段也要同步進行修改，不然會導致數據不一致
- 如果用存儲過程了支持數據的更新，刪除等操作，如果操作頻繁，就會消耗系統(tǒng)資源
- 在數據量小的情況下，反范式不能體現性能的優(yōu)勢，可能還會讓數據庫的設計更加復雜。
3.3反范式的適用場景
當冗余信息能大幅度提高查詢效率的時候，我們才會采取反范式的優(yōu)化。
增加冗余字段的建議
增加冗余冗余字段一定要符合下面的兩個條件，滿足下面的兩個條件才可以考慮增加冗余字段
①這個冗余字段不需要經常進行修改
②這個冗余字段查詢的時候不可或缺
4.BCNF(巴斯范式)
這個表符合第三范式
碼出八股文_斬出offer線八股文導航（持續(xù)更新）
字節(jié)面試：如何設計一個秒殺系統(tǒng)
IDEA 官宣全新默認 UI，太震撼了?。?/p>
實習轉正上岸，我經歷了什么？
SQL查找是否”存在”，別再count了！
如果本文對你有幫助，別忘記給我個3連 ，點贊，轉發(fā)，評論，
咱們下期見！答案獲取方式：已贊 已評 已關~
學習更多知識與技巧，關注與私信博主（03）
