資料庫邏輯設計是從事資料庫應用設計、開發、運行維護等各方面工作的一個重要的基礎性工作。根據不同業務和應用需求，確定並遵循資料庫邏輯設計原則，例如按照第三範式開展邏輯設計，不僅能滿足減少數據冗餘、保證數據一致性和完整性、易擴展性和伸縮性等需求，也是保障系統高性能的一個重要基礎。
1、全表掃描案例
從一個案例來看，例如查詢「喜歡語文的所有學生」
--由於%號這裡肯定是走了全表掃描
select id,name,hobby from student where hobby like '%語文%'；
2、原因
select id,name,hobby from student;
ID NAME HOBBY
---------------------
1 小明 語文，數學
2 小紅 英語，語文，數學
3 小林 英語，語文
可以看到如果是這麼設計表的話，把學生的愛好都塞在一個欄位HOBBY中，那麼查詢條件只能寫成like '%語文%'。這裡的根本原因是該表設計不符合規範化設計理論，從而導致了全表掃描。這裡我們就可以看出邏輯設計的重要性了。
1、概念總結
1）將需求轉化成資料庫的邏輯模型
2）通過ER圖的型式對邏輯模型進行展示
3）同所選用的具體的DBMS系統無關
2、名詞解釋
關係：一個關係對應通常所說的一張表
元組：表中的一行即為一個元組
屬性：表中的一列即為一個屬性，每一個屬性都有一個名稱，稱為屬性名
候選碼：表中的某個屬性組，它可以唯一確定一個元組
主碼：一個關係有多個候選碼，選定其中一個為主碼
域：屬性的取值範圍
分量：元組中的一個屬性值
3、ER圖例說明
矩形：表示實體集，矩形內寫實體集的名字
菱形：表示聯繫集
橢圓：表示實體的屬性
線段：將屬性連接到實體集，或將實體集連接到聯繫集
4、數據操作異常及數據冗餘
插入異常：如果某實體隨著另一個實體的存在而存在，即缺少某個實體時無法表示這個實體，那麼這個表就存在插入異常。
更新異常：如果更改表所對應的某個實體實例的單獨屬性時，需要將多行更新，那麼就說這個表存在更新異常。
刪除異常：如果刪除表的某一行來反映某實體實例，失效時導致另一個不同實體實例信息丟失，那麼這個表中就存在刪除異常。
注意：若一個表中存在插入異常，那它肯定存在刪除異常和更新異常。
數據冗餘：是指相同的數據在多個地方存在，或者說表中的某個列可以由其他列計算得到，這樣就說表中存在數據冗餘。
1、第一範式（所有屬性必須是單值）
定義：資料庫表中的所有欄位都是單一屬性，不可再分的。這個單一屬性是由基本的數據類型所構成的，如整數，浮點數，字符串等，換句話說，第一範式要求資料庫中的表都是二維表。(二維表就是由行和列組成的表)
2、第二範式（所有屬性必須依賴於該實體的唯一標識屬性）
定義：資料庫的表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴。部分函數依賴是指存在著組合關鍵字中的某一關鍵字決定非關鍵字的情況。
換句話說：所有單關鍵字的表都符合第二範式。
修改後的：
通俗解釋:
完全依賴：表中只有一個關鍵字(即主鍵)，其他屬性的增刪改查的時候定位到這一行都是依賴此關鍵字的。
第二範式：只能有一個主鍵，不能有復合主鍵，可以就滿足了第二範式。
由於供應商和商品之間是多對多的關係，所以只有使用商品名稱和供應商名稱才可以唯一標識出一件商品，也就是商品名稱和供應商名稱是一組組合關鍵字。
上表中存在以下的部分函數依賴關係
(商品名稱)—>(價格，描述，重量，商品有效期)
(供應商名稱)—>(供應商電話)
3、第三範式（沒有一個非唯一標識屬性依賴於另一個非唯一標識屬性）
定義：第三範式是在第二範式的基礎上定義的，如果數據表中不存在非關鍵欄位，對任意候選關鍵欄位的傳遞函數依賴則符合第三範式。
存在問題：
(分類，分類描述)對於每一個商品都會進行記錄，所以存在數據冗餘，同時也會存在數據deep插入、更新及刪除異常。
4、BC範式
定義：在第三範式的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合BC範式。也就是說如果是復合關鍵字，則復合關鍵字之間也不能存在函數依賴關係
存在下列關係因此不符合BCNF要求：
(供應商)—>(供應商聯繫人)
(供應商聯繫人)—>(供應商)
並且存在數據操作異常及數據冗餘
第一，二，三範式解決的是非主屬性的關係。BC 範式解決的是主屬性的關係；
第一範式：就是原子性，欄位不可再分割，（列屬性不能在細分為子列）
第二範式：就是完全依賴，沒有部分依賴；(非主屬性不能依賴於主鍵的一部分，要完全依賴於主鍵（主鍵是復合鍵）)
第三範式：沒有傳遞函數依賴。(非主屬性之間的依賴)
BC範式： 解決部分主鍵依賴於非主鍵部分（復合關鍵字之間也不能存在函數依賴關係）。
覺得有用的朋友多幫忙轉發哦！後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~