第三章 正規化概念與應用 - sjchen.im.nuu.edu.tw.pptVIP

資料庫系統理論與實務-使用Oracle 關聯式資料庫的功能相依性與正規化 ? Outlines 為什麼要正規化(Normalization)？ 功能相依性 (Functional Dependency, FD) 正規化(Normalization) 正規化的過程 如何由E-R Model從事正規化 總結 (Chapter 10) ? 為什麼要正規化(Normalization)？ 沒有正規化會造成： 容易有資料重覆儲存的浪費情形 資料在做插入、刪除或更新動作時產生異常(Anomalies)情形 正規化的目的： 降低資料重覆性(Data Redundancy) 避免產生插入、刪除或更新可能的異常(Anomalies) 功能相依 (Functional Dependence; FD) 的概念在資料庫設計上，尤其是資料庫正規化，非常重要。 在資料正規化的過程中，每個階段都是以不同相依性 (Dependence) 之類型做為分割表格的依據。 ? 功能相依性 (Functional Dependency, FD) 假如 R(A1, A2,…, An) 代表一個關聯，其中X 與 Y 為關聯 R 中屬性的子集合，則Y功能相依於X可以利用符號寫成： Y ? X (Y 功能相依於 X) 或 X → Y (X 決定 Y) 　 其中，X為決定因素 (Determinant)或left-hand side，Y為相依因素 (Dependent)或right-hand side 一個關聯表格中的數個屬性間之功能相依性可能如: 所在地可決定分公司電話區碼 (即: 所在地?區碼) 郵遞區號可決定地址所在之區域 員工編號可決定員工姓名 (即: 員工編號?姓名) Def：給定一個關聯R，R的屬性子集Y功能相依於R的屬性子集X, 則： 若且唯若(if and only if) 無論何時R的兩個Tuples若有相同的X值時，則必有相同的Y值。 對於關聯R中的每個X值，均有唯一的Y值來對應。 Ex: A1功能相依於Ar (A1→Ar) 在一個關聯上，功能相依的表示方式： 範例： {供應商代號}→{供應商姓名，聯絡電話} {產品代號}→{產品名稱} {供應商代號，產品代號}→{單價，採購量} Trivial(沒價值)及Non-Trivial(非沒價值)相依性 沒價值 (Trivial) 若功能相依右邊之相依因素，為左邊決定因素的部份集合時，稱此功能相依為沒價值的。 Ex: {供應商代號，產品代號}→供應商代號 非沒價值 (Non-Trivial) 若功能相依右邊之相依因素，不為左邊決定因素的部份集合時，稱此功能相依為非沒價值的。 Ex: {供應商代號，產品代號}→單價 Non-Trivial的功能相依性，在後續要談的正規化過程中才具有意義。 功能相依性的種類 功能相依性有幾種型式： 完全功能相依 (Full Functional Dependency) 部份功能相依 (Partial Functional Dependency) 遞移相依 (Transitive Dependency) 鍵值屬性(Key Attribute) 能構成候選鍵的所有屬性。反之，則稱為非鍵值屬性(Non-Key Attribute)。 因為主鍵是由候選鍵所選出，所以主鍵的組成屬性也是鍵值屬性。 Key Attribute範例： 鍵值屬性：學號，身份証字號 非鍵值屬性：姓名，系別，年級，生日，地址 功能相依性範例 假設現在有下面的相依性範例： 完全功能相依 (Full Functional Dependency) 若主鍵是由多個屬性組合而成，且某非鍵值屬性依賴主鍵之全部而非部分時，則稱該欄位“完全相依”於主鍵。 例如： 若主鍵僅由一個屬性所組成，則任一非鍵值屬性必“完全相依”於主鍵。 部份功能相依 (Partial Functional Dependency) 主鍵X (X為屬性子集合) 由多個屬性組成，某非鍵值屬性依賴主鍵之部分時，則稱該屬性“部份相依”於主鍵。 例如： 遞移相依 (Transitive Dependency) 若存在一個非鍵值屬性子集合 Z，使得 X→Z 且 Z→Y 的功能相依性均成立，則稱之 Y 遞移相依於 X。 即：X、Y、Z三個屬性子集合，形成Z依賴X (X→Z)，Y依賴Z (Z→Y) ，即稱為遞移相依。 例如： 功能相依圖(FD Diagram) 學生選課資料的功能相依性(FD) 為： 功能相依性的推導法則－阿姆斯壯定理 (Armstrongs Axioms) 目的：利用已知的功能相依性，透過一些性質，推導出以下可能項目： 其它隱含(Impli