关联式资料库的功能相依性与正规化10-2.ppt

第 10 章 關聯式資料庫的功能相依性與正規化 學習重點 關聯綱要的非正式設計原則 功能相依性 (FD) 根據主鍵的各種正規化形式 正規化形式的一般化定義 (針對多重鍵值) BCNF (Boyce-Codd Normal Form) 關聯綱要的非正式設計原則 (1) 什麼是關聯式資料庫設計？ 如何將屬性分組以形成「良好的」關聯綱要 ?關聯綱要的兩個層次 邏輯的 “使用者視界” 層 儲存體的 “基底關聯” 層 ?本章所說明的設計理論主要是應用在基底關聯上 ?所謂「好的」基底關聯有什麼條件？? 關聯綱要的非正式設計原則 (2) 我們首先討論良好關聯式設計的非正式設計原則 接著討論功能相依性和正規化的正式定義 1NF (First Normal Form，第一正規化形式) 2NF (Second Normal Form，第二正規化形式) 3NF (Third Normal Form，第三正規化形式) BCNF (Boyce-Codd Normal Form， BCNF正規化形式) 第11章將進一步探討其他種類的相依性、更進階的正規化形式，以及關聯式設計演算法 關聯屬性的語意 原則1：同一個關聯中的每個值組應該盡量只表達一個實體或關係實例 不同實體的屬性 (EMPLOYEE、DEPARTMENT、PROJECT) 不要混雜在同一個關聯裡 應該只有外來鍵才會被用來參考其他屬性 實體與關係的屬性應該要盡量分離 目標: 設計關聯綱要時應該盡量要讓每個關聯的意義容易解釋，屬性的意義也應該很容易了解 圖10.1COMPANY關聯式資料庫綱要的簡化版本 值組中的資料重複和更新異常情況 資訊可能會重複儲存 浪費空間 導致更新異常的問題 新增異常 (Insertion anomalies) 刪除異常 (Deletion anomalies) 修改異常 (Modification anomalies) 更新異常的範例 (1) 以這個關聯為例： EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours) 更新異常： 變更計畫編號P1的計畫名稱，從 “Billing” 改成 “Customer-Accounting” 可能會導致必須修改在計畫P1上工作的所有100位員工的資料 更新異常的範例 (2) 以這個關聯為例： EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours) 新增異常： 若要新增一個計畫就一定要指派員工 相反的 若要新增員工就一定要為他指派計畫 更新異常的範例 (3) 以這個關聯為例： EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours) 刪除異常： 如果要刪除某個計畫，將會導致在該計畫上工作的所有員工也會被刪除 反過來看，如果某位員工是該計畫唯一的工作人員，則刪除該位員工將會導致該計畫也會被刪除 圖10.3這兩個關聯綱要都有更新異常的問題 圖10.4EMP_DEPT和EMP_PROJ的關聯狀態 針對資料重複和更新異常的原則 原則2： 設計基底關聯時必須避免發生新增、刪除或修改異常的情形 假如發現任何異常情況，要清楚的記錄下來，並確定程式能正確更新資料庫 值組中的空值 原則3： 盡量別讓基底關聯中的屬性值經常為NULL 內容值經常是NULL的屬性應該要放在另外分開的關聯中 (還有主鍵) ?空值可以有許多種解釋： 這個值組沒有這個屬性值 這個值組的這個屬性值不知道是否存在 已知這個屬性值存在，但不知道它的值 假值組 不好的關聯式資料庫設計可能會導致某些JOIN運算將產生錯誤的結果 不減值合併 (lossless join) 這個特性是為了確保合併動作的結果是有意義的，參見下一章 原則4： 在設計關聯綱要時，若要使關聯資料可以針對屬性使用相等條件進行合併動作，該屬性就必須是主鍵或外來鍵，這樣就可以確保不會產生假值組。因此要盡量讓關聯的相配屬性是（外來鍵，主鍵）的組合，否則這樣的合併動作可能會產生假值組 功能相依性 (1) 功能相依性 (Functional dependency，FD) 它是評估關聯綱要中將屬性分組為關聯是否正確的主要方式 FD和鍵值是用來定義關聯的正規化形式 (normal form) 是從資料屬性之間的意義與相互關係衍生而來的限制 在兩組屬性集合X與Y之間，假如X的值可以唯一決定Y的值，則稱Y功能相依於X，表示成X→Y 功能相依性 (2) 假如任兩個值組的X值相同，Y值也就一定相同，就表示X - Y成立 對於任何關聯實例r(R) 的任何兩個值組t1和t2而言，假如t1[X] = t2[X] 成立，則t1[Y] = t2[Y] 也一定成立 R中的X - Y是指定在所有的關聯實例r(R) 上都成