资料库建置正规化与erd转换成关联表.pptVIP

補充3 資料庫建置—正規化與ERD轉換成關聯表 關聯表資料庫 關聯表名稱(Relation Name) 屬性(Attribute) 屬性集(Attribute Set) 指定某個屬性子集為主鍵(Primary Key) 屬性都會具有屬性名稱(Attribute Name) 與資料類型(Data Type) 資料型態都會有其值域(Domain) BOB資料庫 …範例 關聯表的特性 不含重覆的值組 值組之間是沒有順序的 屬性之間是沒有順序的 所有屬性值都是單元值(Atomic Value)，不可以是一個集合 e.g. {x, y, z} 不可以是一個屬性值 不含重複的值組 因為關聯表本身是一個集合 此一特性隱含了必須要有主鍵的事實 在實際應用上，系統可容許有重複的值組存在(但我們不建議如此做) 值組之間是沒有順序的 按照集合的定義，集合中的元素沒有順序之分 有順序反而造成麻煩： 順序本身也是一種資訊，所以要小心維護其順序 系統必須提供「在第n與第n+1筆間加入一筆」或「請刪除第八筆」的運算 要以那一個屬性做為排順序的依據？還是要以加入的時間先後來排順序？ 通常是查詢後對結果下排序命令 屬性之間是沒有順序的 屬性集也是一個集合 不過大部份的系統並沒有硬性規定 例如： 在VB 中 Employees(“id”) = Employees(0) 所有屬性值都是單元值 (1) 簡化表示法 (2) 容易實現關聯式模式的概念 非正規化關聯表 正規化型式的階層架構 ??第一正規化型式(1NF) by E.F. Codd ??第二正規化型式(2NF) by E.F. Codd ??第三正規化型式(3NF) by E.F. Codd ??廣義3NF─BCNF (Boyce/CoddNormal Form) ??第四正規化型式(4NF) by R. Fagin ??第五正規化型式(5NF) by R. Fagin 又稱為Projection/Join Normal Form (PJ/NF) 正規化型式的階層架構圖 第一正規化型式 (1NF) ??在關聯式模式裡所有關聯表都要符合1NF 為什麼要正規化？ 關聯表的正規化做法, 一般是將關聯表做適當分割 原因: 沒有正規化會造成所有資料擠在同一個 關聯表, 容易有資料重覆儲存的浪費情形 也會造成「更新時的異常現象」(Update Anomalies) 但是也會犧牲某些效能, 如下頁說明… 為什麼要正規化？ 更新異常現象說明 新增:如果“雙魚書局”尚未訂購任何書籍的話, 那麼新增下列資料會有困難 ??這樣會使得主鍵(no, id) 中的id 為虛值 更新異常現象說明 刪除: 刪除“水瓶書局”訂購編號2 號書籍的事實, 由於只有單筆資料, 所以會連“水瓶書局”的其它資訊都刪除了，造成“水瓶書局”是位於“新竹市”的資訊也失去了。 更新異常現象說明 更新: 更改“巨蟹書局”的city 成為“花蓮市”時，就必須一次將底下的六筆記錄更動 功能相依性的定義 ??[功能相依性] (Functional Dependency)：對於一個關聯表R 而言，我們說 R 中的屬性B 功能相依於R 中的屬性 或稱 R 中的A 在功能上決定R 中的B 寫成 R.A→R.B 若且唯若在任何時候R 中的A 屬性值只會對應 到一個R 中的B 屬性值。A 與B 都可以是複合 屬性(Composite Attribute) BO 的功能相依圖 有Update Anomalies：原因是BO中包含了複合主鍵(no, id)，而且其中有一些非候選鍵的屬性(如：name, rank與city) 卻只功能相依於主鍵中的一部份—no 解決方式: 將 BO 拆成兩個表格的 FD 圖 第二正規化型式 第二正規化型式(2NF)：關聯表R 屬於第二正規化型式，若且唯若它為第一正規化型式，而且所有不屬於候選鍵的屬性都完全功能相依於該關聯表的主鍵。 上述定義並沒有規範：不屬於候選鍵的屬性之間，不可以有任何功能相依性。 關聯表Bookstores1 中所有欄位都功能相依於主鍵no以外，尚且存在city→rank的功能相依性, 是屬於非候選鍵屬性之間的功能相依性, 它同樣也會導致更新的異常現象發生 city→rank 所造成的異常現象 新增：雖然city→rank，但是我們無法記錄某個城市的rank(例如：永和市的rank為35)，除非真有這樣的書局存在，因為這樣會造成no的屬性值為虛值，而違反了主鍵不能為虛值的限制條件！ 刪除：若只想刪除某書店(例如：“獅子書局”)，但想保留它所在城市的rank，將無法達成。因為刪除(5, “獅子書局”, 30, “臺南市”) 則“臺南市”的rank為30 也一併