第5章 資料庫的正規化.

Presentation on theme: "第5章 資料庫的正規化."— Presentation transcript:

1 第5章 資料庫的正規化

2 大綱 6.1 前言 6.2 資料庫正規化的型式與義涵 6.3 資料庫正規化 6.4 另一個正規化例子 6.5 一個簡易方法–類聚檢查法

3 6.1 前言 資料庫正規化(Normailzation)技術 邏輯資料庫架構設計 合併(Join)運算
專門用來設計邏輯資料庫架構 邏輯資料庫架構設計 將資料項(Data Item)分門別類後 將資料項分別安排在不同的資料表中 建立起彼此的關聯(Relation) 合併(Join)運算 反正規化(De-Normalization)

4 6.2 資料庫正規化的型式與義涵 正規化型式 第一正規化型式(First Normal Form， 簡稱1NF)
第二正規化型式(Second Normal Form， 簡稱2NF) 第三正規化型式(Third Normal Form， 簡稱3NF) Boyce/Codd正規化型式(Boyce/Codd Form， 簡稱BCNF) 第四正規化型式 第五正規化型式

5 6.2 資料庫正規化的型式與義涵

6 6.3 資料庫正規化 【定義】第一正規形式(First Normal Form， 簡稱1NF)
表格沒有重複出現的欄位，且表格中每一筆記錄的每一個欄位只能存放單一的資料值

7 6.3 資料庫正規化 第一正規化乃在消除資料表上的重複資料 一個表格中若有重複的欄位，應該將之分割，放置在不同的資料表中
一個欄位若有多個資料值，也應該將之分割，放置在不同的紀錄裡 除了供應商代號及供應商姓名兩個欄位外，其餘欄位均有兩個資料值，因此不符合第一正規形式，必須將之分割到不同的紀錄上

8 6.3 資料庫正規化 考慮供貨紀錄表(表6.2) 刪除異常 新增異常 修改異常
倘若S04結束營業，其供貨紀錄將被刪除，則連 同SM05的相關資訊也會被一併刪除，因而造成資 料的流失 新增異常 若有一家新超市開業，它尚未找到合適的供應商 ，這時若硬要將超市的資訊加入到供貨紀錄資料 表，則會因有些鍵值是空白而產生異常 修改異常 例如SM01的助理由MARY換成LINDA，若只更新 了R2而忘了更新R3及R8，也會造成資料的不一 致

9 6.3 資料庫正規化 功能相關(Functional Dependency)，或稱「相依」 供貨紀錄表(表6.2)上十個欄位屬性間之相依關係
QTY完全功能相關(Fully Functional Dependency)於 「SNO、PNO、SMNO」

10 6.3 資料庫正規化

11 6.3 資料庫正規化

12 6.3 資料庫正規化

13 6.3 資料庫正規化 【定義】第二正規化(Second Normal Form， 簡稱2NF)
若且唯若關聯R為1NF且紀錄中的每一非鍵欄位 都完全相關於主鍵(PK) 每一個欄位只能與主鍵相依 每一個欄位只能由主鍵來唯一識別，但不可其中某些欄位可由主鍵的一部份來識別 將1NF轉化為2NF之過程即在消除非鍵欄位與主鍵間之部份功能相依。

14 6.3 資料庫正規化 2NF很明顯地改善了1NF的缺點
例如S04突然宣告倒閉，它的資料從「供應商資料表」剔除之後，SM05的資訊依然完整的保存在「超市經理資料表」裡 然而如果SM05關門大吉，自「超市經理資料表」將整筆記錄刪除之後，我們就無法查出北區的區長是誰了？

15 6.3 資料庫正規化 【定義】第三正規化(Third Normal Form， 簡稱3NF)
若且唯若關聯R為2NF且紀錄中的每一非鍵欄位之屬性 都不具有遞移相關於主鍵(PK)之特性 將2NF轉化為3NF之過程即在消除遞移相依

16 6.3 資料庫正規化

17 6.3 資料庫正規化 多重值相關Multi-Valued Dependency) 超市助理資料表
一家超市均有可能對應到多位助理以及多支電話(例如SM04超市擁有JOHN和JANE兩位超市助理，而SM01超市擁有 和 兩支電話)

18 6.3 資料庫正規化 多重值相關Multi-Valued Dependency) 「超市助理」多重值相關於「超市代號」
「電話」也多重值相關於「超市代號」 表示這張資料表中有太多重複資料 這對於資料的更新異動會產生許多異常現象 需將超市助理資料表分割成兩張資料表

19 6.3 資料庫正規化

20 資料庫正規化 【定義】第四正規化(Forth Normal Form， 簡稱4NF) 若且唯若關聯R為3NF且每當R中存在著一對多值相關
(Multi Valued Dependency)的屬性，如AB， 則關連R之其他屬性最多只能功能相關於A

21 6.3 資料庫正規化 簡易實體關係圖(Entity Relationship Diagram， 簡稱ERD) 主鍵與外來鍵之關係
資料表間是以哪些欄位做合併(Join)

22 6.4 另一個正規化例子 設計一個「銷售資料庫-SaleDB」 資料項 訂單序號 訂貨日期 單價 庫存量等 …

23 6.4 另一個正規化例子 原始資料

24 6.4 另一個正規化例子 正規化的過程 【步驟1】 去除重複資料，將表6.5分割成表6.6及表6.7

25 6.4 另一個正規化例子

26 6.4 另一個正規化例子 【步驟2】 先由表6.7下手 由「訂單序號」+「產品代號」可以決定出「訂購數量」
由「產品代號」可以決定出「產品名稱」、「單價」及「庫存量」 須滿足：「每一非鍵欄位都完全相關於主鍵(PK) 」 將表6.7分割成分別以「訂單序號」+「產品代號」以及「產品代號」為主鍵的兩張資料表，即表6.8及表6.9

27 6.4 另一個正規化例子

28 6.4 另一個正規化例子 【步驟3】 從表6.6得知 由「訂單序號」可以決定出「訂貨日期」、「送貨日期」及「客戶代號」
由「客戶代號」可以決定出「客戶名稱」及「客戶地址」 去除遞移相依 將表6.6分割成表成分別以「訂單序號」及「客戶代號」為主鍵的兩張資料表，即6.10及表6.11

29 6.4 另一個正規化例子

30 6.5 一個簡易方法–類聚檢查法 物以類聚 物：資料項 類：實體(Entity)、資料表 檢查是否符合第一、第二及第三正規化型式

31 6.5 一個簡易方法–類聚檢查法 【步驟1】 分析問題，收集所有資料項 訂單序號 訂貨日期 送貨日期 產品代號 客戶代號 訂購數量 客戶名稱
客戶地址 產品代號 訂購數量 產品名稱 單價 庫存量等

32 6.5 一個簡易方法–類聚檢查法 【步驟2】 分析問題，找出實體(Entity) Product(產品)實體 Customer (客戶)實體
存放所有與產品有關的資料 Customer (客戶)實體 存放所有與客戶有關的資料 Orders (訂單)實體 存放客戶的訂購資訊

33 6.5 一個簡易方法–類聚檢查法 【步驟3】 將資料項分類，逐一擺放到適當的實體裡，並且須滿足： 因此，我們得到以下結果：
每一個實體都有一個主鍵 實體與實體間必須至少有一關連互相聯繫，使實體不致於成為孤島 因此，我們得到以下結果：

34 6.5 一個簡易方法–類聚檢查法

35 6.5 一個簡易方法–類聚檢查法 【步驟4】 檢查每一個實體是否符合1NF、2NF、3NF
我們發現「Orders」實體中，一個訂單序號可能訂購好幾項產品，因而造成訂貨日期、送貨日期及客戶代號等資料會大量地重複 下表中陰影部分的資料皆重複了

36 6.5 一個簡易方法–類聚檢查法 很自然地我們將「Orders」實體分割成「Orders」實體和「Orderslist」實體，兩者以訂單序號相互聯繫，即

37 6.5 一個簡易方法–類聚檢查法 【步驟5】 畫出實體關係圖