9 規範資料庫設計

9.1 為什麼要規範化資料庫設計？

　　當資料庫比較複雜的時候，我們就需要設計了。

9.1.1 糟糕的資料庫設計

• 資料冗餘、浪費空間

• 資料庫插入和刪除都會麻煩、異常【遮蔽使用物理外來鍵】

• 程式的效能差

9.1.2 良好的資料庫設計

• 節省記憶體空間

• 保證資料庫的完整性

• 方便我們開發系統

軟體開發中，關於資料庫的設計：

• 分析需求：分析業務和需要處理的資料庫的需求

• 概要設計：設計關係圖E-R圖

9.1.3 設計資料庫的步驟（以個人部落格為例）

• 收集資訊，分析需求

  • 使用者表：用於登入登出，使用者的個人資訊，寫部落格，建立分類

  • 分類表：文章分類，誰建立的

  • 文章表：文章的資訊

  • 評論表

  • 友連結串列：友鏈資訊

  • 自定義表：系統資訊，某個關鍵的字或者一些主欄位 key：value

  • 說說表：發表心情：id、content、create time...

• 標識實體：把需求落實到每個欄位

• 標識實體之間的關係

  • 寫部落格：user---部落格

  • 建立分類：user---category

  • 關注：user---user

  • 友鏈：links

  • 評論：user---user---blog

主要過程：

建立xiaocui_blog資料庫，在表中新建如下表：

user表：

category表：

blog表：

comment表：

user_follow表：

links表：

9.1.4 為什麼需要資料規範化？

• 資訊重複

• 更新異常

• 插入異常

  • 無法正常顯示資訊

• 刪除異常

  • 丟失有效的資訊

關於規範資料庫設計涉及到規範性和效能的問題：

　　關聯查詢的表不得超過三張表

• 考慮商業化的需要和目標（成本，使用者體驗），資料庫的效能更加重要

• 在規範效能問題的時候，需要適當的考慮一下規範性！

• 故意給某些表增加一些冗餘的欄位，從多表查詢中變為單表查詢

• 故意增加一些計算列，從大資料量降低為小資料量的查詢：索引

9.2 三大正規化

　　參考連結： https://www.cnblogs.com/wsg25/p/9615100.html

目前關係資料庫有六種正規化：第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）、巴斯-科德正規化（BCNF）、第四正規化(4NF）和第五正規化（5NF，又稱完美正規化）。而通常我們用的最多的就是第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF），也就是本文要講的“三大正規化”。

9.2.1 第一正規化（1NF）

　　要求資料庫表的每一列都是不可分割的原子資料項

　　即：列的原子性，保證每一列不能再分

舉例：

在上面的表中，“家庭資訊”和“學校資訊”列均不滿足原子性的要求，故不滿足第一正規化，調整如下：

可見，調整後的每一列都是不可再分的，因此滿足第一正規化（1NF）。

9.2.2 第二正規化（2NF）

　　在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函式依賴）

　　第二正規化需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）

　　即：不能包含部分依賴，每張表只描述一件事情

舉例說明：

在上圖所示的情況中，同一個訂單中可能包含不同的產品，因此主鍵必須是“訂單號”和“產品號”聯合組成，但可以發現，產品數量、產品折扣、產品價格與“訂單號”和“產品號”都相關，但是訂單金額和訂單時間僅與“訂單號”相關，與“產品號”無關，這樣就不滿足第二正規化的要求，調整如下，需分成兩個表：

9.2.3 第三正規化（3NF）

　　在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）

　　第三正規化需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關

　　即：不能包含傳遞依賴

舉例說明：

上表中，所有屬性都完全依賴於學號，所以滿足第二正規化，但是“班主任性別”和“班主任年齡”直接依賴的是“班主任姓名”，而不是主鍵“學號”，所以需做如下調整：

這樣以來，就滿足了第三正規化的要求。

ps:如果把上表中的班主任姓名改成班主任教工號可能更確切，更符合實際情況，不過只要能理解就行。