功能相依.ppt

關聯式資料庫的功能相依性與正規化 學習重點 關聯綱要的非正式設計原則 非正式原則：屬性的語意 非正式原則：減少重複值 非正式原則：避免空值 非正式原則：避免產生假值組 功能相依性 功能相依性的推論規則 正規化的一般程序 關聯的正規化 第一正規化形式 第二正規化形式 第三正規化形式 BCNF正規化形式 資料庫的設計原則 什麼是好的關聯式資料庫設計？ 為什麼把某些屬性組成關聯綱要(relational schema)要比其他的組成方式好？ 建置好的關聯綱要，可以從兩個層次說明 邏輯層(logical level)：或稱概念層(conceptual level)，能讓使用者清楚明瞭在關聯中資料的含意，進而能讓使用者正確的進行資料查詢 主要著重在關聯和視界的綱要 實作層(implementation level)：或稱儲存層(storage level)，影響到關聯中值組如何儲存和更新 應用在基底關聯(base relation)的綱要上 正是本章所要說明的設計理論 關聯綱要的非正式設計原則 良好關聯式設計的非正式設計原則 屬性的語意(semantic) 減少值組中的重複值(redundant value) 減免值組為NULL值(null value) 不允許產生假值組(spurious tuple) 屬性的語意 語意(semantic)：就是指如何解釋儲存在關聯值組中的屬性值 也就是說值組中屬性值之間的關係 例如，員工(Employee)值組的資料 員工姓名(Ename) 社會安全號碼(Ssn) 生日(Bdate) 地址(Address) 員工工作的部門編號(Dnumber) 非正式原則：屬性的語意 原則1：一個關聯綱要應該直接對應一個實體類型或一個關係類型 盡量不要將多個實體類型和關係類型的屬性結合在同一個關聯中 不同實體的屬性 (EMPLOYEE、DEPARTMENT、PROJECT) 不要混雜在同一個關聯裡 應該只有外來鍵(foreign key)才會被用來參考其他屬性 實體與關係屬性應該要盡量分離 目標: 設計關聯綱要時應該盡量要讓每個關聯的意義容易解釋，屬性的意義也應該很容易了解 COMPANY資料庫綱要的簡化版本 COMPANY資料庫狀態的範例 值組中的資料重複和更新異常情況 常見的關聯設計不良問題 將不同實體的屬性混雜在一起 如圖10.3(a)，員工和部門的屬性混合在EMP_DEPT中 資訊重複儲存而浪費空間 更新異常的問題 新增異常 (Insertion anomalies) 刪除異常 (Deletion anomalies) 修改異常 (Modification anomalies) 關聯設計不良的範例：關聯綱要 關聯設計不良的範例：資料庫狀態 更新異常範例 (1/2) 以這個關聯為例： EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours) 新增異常： 若要新增一筆員工資料至EMP_DEPT，就必須也要新增員工的部門資料，或是以NULL值代替 若要新增一筆在5號部門工作的員工，則此時也必須正確輸入5號部門的相關屬性值 無法新增一筆部門資料，而沒有輸入任何員工資料 因為在EMP_DEPT的主鍵是Ssn，所以不能只填部門資料而在員工屬性中輸入NULL值 更新異常範例 (2/2) 刪除異常： 如果要從EMP_DEPT刪除一位員工的資料，而這位員工又是這個部門唯一的一位員工 這筆部門資料也會一併從資料庫刪除 如果要從EMP_PROJ刪除某個計畫，將會導致在該計畫上工作的所有員工也會被刪除。 如果某位員工是該計畫唯一的工作人員，則刪除該位員工將會導致該計畫也會被刪除 修改異常： 在EMP_PROJ中，如果修改某計劃的名稱，那麼就必須修改在此計劃工作的所有員工資料 有可能導致必須修改在此計畫上工作的所有100位員工的資料 (不能只修改部份) 非正式原則：減少重覆值 原則2：設計基底關聯時必須避免發生新增、刪除或修改異常的情形。 假如發現任何異常情況，要清楚的記錄下來，並確定程式能正確更新資料庫 值得一提的是，有時為了改善資料查詢的效能，反而會故意違反這些原則。 例如，若有重要的查詢需要同時擷取員工屬性和其部門，也許就會使用EMP_DEPT來當作基底關聯 此時，就要特別注意EMP_DEPT的更新異常問題 非正式原則：避免空值 原則3：盡量別讓基底關聯中的屬性值經常為空值(NULL) 內容值經常是NULL的屬性，應該要放在另外分開的關聯中 (還有主鍵)。因為 空值浪費空間 空值可能有不同的含意 空值可能造成使用COUNT或SUM這類聚合運算時，不知如何計算 ?空值可以有許多種解釋： 這個值組沒有這個屬性值 這個值組的這個屬性值不知道是否存在 已知這個屬性值存在，但不知