CH 5 邏輯資料庫設計與關聯式模型 關聯式資料模型、關聯式資料模型元件、關聯表（ Relation ）、關聯表的必要條件

Presentation on theme: "CH 5 邏輯資料庫設計與關聯式模型 關聯式資料模型、關聯式資料模型元件、關聯表（ Relation ）、關聯表的必要條件"— Presentation transcript:

1 CH 5 邏輯資料庫設計與關聯式模型 關聯式資料模型、關聯式資料模型元件、關聯表（ Relation ）、關聯表的必要條件
鍵欄位（ Key Fields ）：主鍵、外來鍵、次要鍵、候選鍵、替代鍵 如何挑選最好的主鍵 外來鍵(Foreign Keys) 定義及範例 關聯表綱要表示法 外來鍵參考圖及環 外來鍵(Foreign Keys)之特殊情形 完整性限制（ Integrity Constraints ）：值域限制（區域完整性 ）、實體完整性、參考完整性、行動主張 外來鍵參考對象的刪除/更新規則：限制性做法、連鎖反應的做法、虛值化的做法、設定預設值 Well-Structured Relations avoid anomalies（避免異常） Transforming EER Diagrams into Relations的7 個步驟： 步驟一：對應一般實體到關聯 步驟二：對應弱勢實體 步驟三：對應二元關係 步驟四：對應聯合實體 步驟五：對應一元關係 步驟六：對應三元或多元關係 步驟七：對應超類型/子類型關係 CH 5 資料庫

2 邏輯資料庫設計與實體資料庫設計 資料庫分析後的資料儲存需求，轉換成指引資料庫實作的規格，有兩種形式： 邏輯資料庫設計：
將概念性資料模型轉換成邏輯資料模型的過程 著重關聯式資料模型 實體資料庫設計： 指明所有資料儲存所需的參數，然後輸入給資料庫實作；真正定義了一個資料庫 CH 5 資料庫

3 關聯式資料模型（式） IBM 研究員E. F.Codd 在1970 年所提出，有兩個雛型系統： System R：
Ingres： 加州柏克萊開發的學術導向ＲＤＢＭＳ CH 5 資料庫

4 關聯式資料模型元件 關聯式資料模型，包括3 個元件： 資料結構： 以列（row）與欄位（column）組成表格的形式來組織資料 資料操作：
利用強大的運算（ＳＱＬ語言）來操作儲存在關聯表中的資料 資料完整性： 加入設定業務法則的工具，使得操作資料的同時，還能保有完整性 CH 5 資料庫

5 關聯表（ Relation ） 定義： A relation is a named, two-dimensional table of data 一種有命名的二維資料表 由 rows (records)和 columns (attribute or field)所組成 每個關聯表由列（記錄）與欄位（屬性）所組成 注意： Not all tables qualify as relations 並非所有表格都有資格成為關聯表 CH 5 資料庫

6 關聯表的特性/必要條件 Properties /Requirements of Relation
Every relation has a unique name. 每個關聯表都有唯一的名稱 Every attribute value is atomic (not multivalued, not composite) 每個屬性值都是不可分割 （不能是多值﹐也不能是複合值） Every row is unique (can’t have two rows with exactly the same values for all their fields) 每一列都是唯一的，沒有兩列有全部一樣的欄位值 Attributes (columns) in tables have unique names 每個屬性（或欄位）都有唯一的名稱 The order of the columns is irrelevant 欄位的順序是無關緊要的 The order of the rows is irrelevant 列的順序是無關緊要的 註：所有的關聯表都是第一正規化形式 CH 5 資料庫

7 與 ER 模型的對應 關聯表對應到實體類型及多對多的關係類型 列對應到實體類型實例及多對多的關係實例 欄位對應到屬性
註：關聯式資料庫中的relation 與ER模型中的 relationship 是不同的字 CH 5 資料庫

8 鍵欄位（ Key Fields ） 鍵：可以是單一鍵(單一欄位) or 複合鍵(超過一個欄位) 鍵：通常用來當作索引，以加速使用者查詢的回應
CH 5 資料庫

9 鍵欄位（ Key Fields ） －主鍵 Primary keys （主鍵）：
are unique identifiers of the relation .This is how we can guarantee that all rows are unique. 關聯表中具有唯一性的識別子﹐如員工代號、身分證字號等 用它來保證所有列都是獨特的 一個可以明確指出獨一無二唯一記錄的欄位 CH 5 資料庫

10 鍵欄位（ Key Fields ） －外來鍵 Foreign keys （外來鍵）：
are identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship). 一種識別子 讓相依的關聯表（關係之多基數邊）能參考到它的父關聯表（關係之單基數邊） 關聯表（多基數邊，many side）的外來鍵欄位用於連結到另一個關聯表（單基數邊，one side）的主鍵欄位 CH 5 資料庫

11 鍵欄位（ Key Fields ） －次要鍵 次要鍵（ Secondary Key ）：
又稱 nonunique key（非唯一鍵），對於此欄位, 多筆記錄資料會有相同值 CH 5 資料庫

12 鍵欄位（ Key Fields ） －候選鍵 候選鍵（Candidate key）：
A unique identifier（唯一的識別字）. One of the candidate keys will become the primary key 關聯表同時有多個識別字可被選為 primary key（主鍵），這些識別字都是候選鍵；主鍵就是由這些候選鍵選出其一 例如：一個關聯表含有credit card number 和 ID，則這兩個識別字都是candidate keys 候選鍵應具備的條件： 唯一性(Unique Property)： 沒有兩個值組的候選鍵有相同的值 最小性(Irreducibility Property，或Minimality)： 該屬性子集如果去除任一個屬性時，便不再符合唯一性 最極端情形：所有屬性皆構成資料表的候選鍵 例如：work_in ( employee_id，department_id ) CH 5 資料庫

13 鍵欄位（ Key Fields ） －替代鍵 替代鍵（Alternate key）： 沒有被選為主鍵的候選鍵，稱為替代鍵 CH 5 資料庫

14 如何挑選最好的主鍵 選擇永不會變更其值的屬性 確保不會是虛值的屬性 不要用人工才能解讀的編號鍵值 儘量以單一的屬性來代表整筆值組
如：身份證字號，學號等。 確保不會是虛值的屬性 不要用人工才能解讀的編號鍵值 例如，原料代號A5838 中的A 代表某一倉庫位置，但倉庫卻可能常常更換 儘量以單一的屬性來代表整筆值組 例如：一個球類比賽的關聯表 game (home_team，visiting_team，比賽時間，….)  game (game_no，home_team，visiting_team，比賽時間，….) CH 5 資料庫

15 外來鍵(Foreign Keys) EMPLOYEE1（Emp_ID，Name，Dept_Name，Salary）
通常我們靠外來鍵來表達兩個關聯表的關係 外來鍵是某一個關聯表的一或一組屬性，而它同時也是另一個關聯表的主鍵 例如： EMPLOYEE1（Emp_ID，Name，Dept_Name，Salary） DEPARTMENT（Dept_Name，Location，Fax） Dept_Name屬性是EMPLOYEE1的外來鍵,它讓使用者可結合員工與所屬的部門 CH 5 資料庫

16 外來鍵定義 C 注意：R1與R2 可以是同一個關聯表 R2資料表的FK屬性是外來鍵，關聯到R1資料表的CK主鍵
R2 中的外來鍵（FK），若參考到關聯表R1的候選鍵（CK），則所有R2中的FK值一定要符合下列其中一項條件： 全部的值都是可適用的虛值，或 等於R1中某值組的候選鍵 R2 PK FK 其他屬性 B － C R1 CK（PK） 其他屬性 A B C 注意：R1與R2 可以是同一個關聯表 CH 5 資料庫

17 外來鍵(Foreign Keys) － 範例：書局資料表
Bookstores( no, name, rank, city) No name rank city 1 巨蟹書局 20 台北市 2 射手書局 10 高雄市 3 水瓶書局 30 新竹市 4 天秤書局 台中市 5 獅子書局 台南市 CH 5 資料庫

18 外來鍵(Foreign Keys) － 範例：書籍資料表
Books (id，bookname，author，price，publisher ) Id book name author price publisher 1 三國演義 羅貫中 120 古文出版社 2 水滸傳 施耐庵 170 中庸出版社 3 紅樓夢 曹雪芹 春秋出版社 4 西遊記 吳承恩 140 聊齋出版社 5 水經注 酈道元 易經出版社 6 道德經 老子 190 大唐出版社 CH 5 資料庫

19 外來鍵(Foreign Keys) － 範例：訂單資料表
no id quantity 1 30 2 20 3 40 4 5 10 6 訂單資料表 Orders( no, id, quantity) CH 5 資料庫

20 關聯表綱要表示法 關聯表綱要表示法： Books( id，bookname，author，price，publisher)
Orders( no ， id ， quantity) Bookstores( no，name，rank， city) no 及 id 為 orders 關聯表的外來鍵 orders.no  bookstores.no orders.id  books.id Orders 的 id 屬性是外來鍵，關聯到Books的id 主鍵 Orders 的 no 屬性是外來鍵，關聯到Bookstores的no 主鍵 CH 5 資料庫

21 外來鍵(Foreign Keys) － 範例 在orders中，值組（8，7，50）不是一個合法的值組。why？ CH 5 資料庫

22 外來鍵參考圖及環 Bookstores ← Orders → Books 外來鍵參考鏈（Referential chain）：
Rn → Rn-1 →…. → R1 外來鍵參考環（Referential cycle）： Rn → Rn-1 →…. → R1 → Rn no id CH 5 資料庫

23 外來鍵(Foreign Keys)之特殊情形
manager屬性是外來鍵，關聯到本身資料表的eno主鍵 外來鍵也可以參考本身的屬性 ： employees (eno，name，manager，salary) 外來鍵不一定是關聯表之主鍵的一部份： 例：departments (dno，name，manager，budget) manager屬性是外來鍵，但不為主鍵 例： employees (eno，name，dno，salary) dno屬性是外來鍵，但不為主鍵 CH 5 資料庫

24 松谷傢具資料庫之4個關聯表的綱要 （ Fig. 5-3 ）
主鍵 外來鍵 (實作CUSTOMER與ORDER之間的一對多關係) 組合的﹐這些是複合主鍵 (唯一地識別出ORDER LINE)…它們個別都是外來鍵 (實作ORDER與PRODUCT之間的多對多關係) CH 5 資料庫

25 完整性限制（ Integrity Constraints ）
完整性限制: 關聯式資料模型包括幾種的限制，或業務法則 目的： 為了維護資料庫中有關資料的正確性及完整性 並用來規範資料在關聯表中的儲存、刪除或更改動作，以防止不一致或錯誤的情況發生 CH 5 資料庫

26 完整性限制種類 值域限制（domain constraint）： 實體完整性（Entity integrity）：
又稱 區域完整性 (Domain Integrity)，確保資料在允許的範圍 Allowable values for an attribute. （屬性的容許值）﹐請參閱p 5-8 表5-1 值域包含右列元件：值域名稱、意義、資料型態、大小（長度）、及可允許的值或範圍 實體完整性（Entity integrity）： No primary key attribute may be null. （任何主鍵屬性都不可為null ） All primary key fields MUST have data.（所有的主鍵欄位都必須有資料） 規範關聯表內部的限制條件 確保關聯表中的記錄是 “唯一” 參考完整性（referential integrity）： 規範關聯表與關聯表之間的限制條件 確保相關連的關聯表間資料一致, 避免因一個關聯表的記錄改變, 造成另一個關聯表的內容變成無效的值 行動主張（action assertion）： 業務法則﹐請回顧第4章 又稱使用者定義的完整性 (User-defined Integrity) ，由使用者自行定義 CH 5 資料庫

27 實體完整性（entity integrity）
實體完整性只適用於基底關聯表 關聯表的主鍵： 不可為某個內定值，更不可為虛值（Null） 若主鍵為虛值表示該個體是一個完全不確定的實體 若主鍵為複合屬性所組成，則所有屬性皆不可為虛值 主鍵的目的： 使每個實體都可以分辨 查詢處理的方便性及務實性 例如：請問下列關聯表含有幾家書局的資料？ 不知道 no name rank city 1 巨蟹書局 20 台北市 － 10 高雄市 CH 5 資料庫

28 參考完整性（referential integrity） －外來鍵的值
外來鍵的值（關係之多基數邊的關聯表）： any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side. (Or the foreign key can be null) 必須在另一邊的關聯表中找到一個主鍵值與之相配，否則該外來鍵的值就必須是null 資料庫中不可有違法的外來鍵 外來鍵的虛值規則(Null Rule for Foreign Key)： 既是外來鍵又是主鍵的屬性不可以新增或更改為虛值 例如：orders.no 及orders.id 外來鍵不是主鍵的一部份，可視情況允許為虛值 CH 5 資料庫

29 參考完整性限制 (松谷傢具) Fig. 5-5 參考完整性限制的表示法： 從相依表格（外來鍵）連到父表格（主鍵）的箭頭 CH 5 資料庫

30 參考完整性（referential integrity） －外來鍵參考對象的刪除/更新規則
外來鍵參考對象的刪除/更新規則(Delete/Update Rule for Foreign Key Reference) ： 定義外來鍵的參考對象刪除或更新後，如何維持參考完整性 分成以下四種做法： 限制性做法(RESTRICTED) 連鎖反應的做法(CASCADES) 虛值化的做法(NULLIFIES、Set-to-Null) 設定預設值(Set Default) CH 5 資料庫

31 外來鍵參考對象的刪除/更新規則 －1. 限制性做法(RESTRICTED)
如果在相依表格中存在相關的列﹐則不允許刪除父表格的列 定義： don’t allow delete of “parent” side if related rows exist in “dependent” side. 欲刪除/更新某關聯表（one side）某一值組時，若參考它的外來鍵有相對的值組，則不可以做刪除/更新；否則可以。 CH 5 資料庫

32 外來鍵參考對象的刪除/更新規則 －範例關聯表
No name rank city 1 巨蟹書局 20 台北市 2 射手書局 10 高雄市 3 水瓶書局 30 新竹市 4 天秤書局 台中市 5 獅子書局 台南市 no id quantity 1 30 2 20 3 40 4 5 10 6 Id book name author price publisher 1 三國演義 羅貫中 120 古文出版社 2 水滸傳 施耐庵 170 中庸出版社 3 紅樓夢 曹雪芹 春秋出版社 4 西遊記 吳承恩 140 聊齋出版社 5 水經注 酈道元 易經出版社 6 道德經 老子 190 大唐出版社 CH 5 資料庫

33 外來鍵參考對象的刪除/更新規則 －1. 限制性做法的範例
請參考前一頁範例關聯表 例如：欲刪除Bookstores 的(4，’天秤書局’，20，’台中市’) 則不可刪除此筆資料，因為ORDERS中NO=4有3筆記錄存在 在沒有刪除Orders 中所有含(4，……..) 記錄以前，不准刪除 Bookstores 中的 (4，’天秤書局’，20，’台中市’) 例如：欲刪除Bookstores 的(5，’獅子書局’，30，’台南市’) 則可以刪除此筆資料，因為ORDERS中沒有NO=5的記錄存在 例如：欲刪除Bookstores 的(3，’水瓶書局’，30，’新竹市’) 則不可刪除此筆資料，因為ORDERS中NO=3有1筆記錄存在 CH 5 資料庫

34 外來鍵參考對象的刪除/更新規則 －2. 連鎖反應做法(CASCADES)
刪除父表格的列時﹐自動刪除相依表格的對應列 定義： automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted. 欲刪除/更新某關聯表某一值組時，若參考它的外來鍵有相對的值組，則在刪除/更新後也要一併刪除/更新外來鍵端所有相對的匹配值組 否則只要直接刪除/更新該筆值組即可 CH 5 資料庫

35 外來鍵參考對象的刪除/更新規則 －2. 連鎖反應做法的範例
請參考前面的範例關聯表 例如：欲刪除Bookstores 的(4，’天秤書局’，20，’台中市’) 則刪除此筆資料時，因為ORDERS中NO=4有3筆記錄存在，亦要跟著刪除 例如：欲刪除Bookstores 中的(5，’獅子書局’，30，’台南市’) 則直接可以刪除此筆資料，因為ORDERS中沒有NO=5的記錄存在，所以不用刪除ORDERS相對記錄。 注意: 此種方法可能會引起連鎖反應 連鎖反應： R3 → R2 → R1 刪除R1，使得R2相對值組亦要刪除，且可能引起 R3亦要刪除相對值組 這些動作必須同時完成，亦即整個連鎖反應動作看成是一個完整的異動（transaction），若其中有一個步驟為錯誤，則必須全部不作 CH 5 資料庫

36 外來鍵參考對象的刪除/更新規則 －3.虛值化做法(NULLIFIES、Set-to-Null)
注意： Not allowed for weak entities. 若為弱勢實體則不可以使用此法，也就是不允許設為null 若該外來鍵是主鍵，也不可以使用此法 定義： set the foreign key in the dependent side to null if deleting from the parent side. 欲刪除/更新某關聯表某一值組時，若參考它的外來鍵有相對的值組時，則在刪除/更新後，也要一併刪除/更新外來鍵端所有相對的匹配值組的外來鍵值改為null 否則只要直接刪除/更新該筆值組即可 CH 5 資料庫

37 外來鍵參考對象的刪除/更新規則 －3.虛值化做法的範例一
請參考前面的範例關聯表 例如：欲刪除Bookstores的(5，’獅子書局’，30，’台南市’） 則直接刪除此筆資料，因為ORDERS中沒有NO=5的筆記錄，所以ORDERS不用虛值化 例如：欲刪除Bookstores的(4，’天秤書局’，20，’台中市’) 則刪除此筆資料時，因為ORDERS中NO=4有3筆記錄，所以理論上ORDERS相對值組的NO=4欄位必須要設為null 但是，ORDERS以NO欄位為主鍵的一部份，則不可設為null，亦即不可用此法 CH 5 資料庫

38 外來鍵參考對象的刪除/更新規則 －3.虛值化做法的範例二
可以使用虛值化做法的情況： employees (eno，name，manager，salary) employees eno name manager salary A001 Mike － 60k E001 Frank 80k E002 John 48k S001 Tom 70k Manager 為外來鍵，參考本身資料表的eno主鍵 CH 5 資料庫

39 外來鍵參考對象的刪除/更新規則 －3.虛值化做法的範例二（續）
例如：根據前一頁的關聯表，若欲刪除employees (E001, Frank, ─, 80k) ，可以刪除嗎？ 可以 但是，employees (E002, John, E001, 48k)這筆記錄中，E002 John員工的主管是E001，必需將此筆紀錄的主管（manager）改成null employees (E002, John, －, 48k) CH 5 資料庫

40 外來鍵參考對象的刪除/更新規則 －4.設定預設值(Set Default)
定義： 欲刪除/更新某關聯表某一值組時，若參考它的外來鍵有相對的值組時，則在刪除/更新後，也要一併刪除/更新外來鍵所有相對的匹配值組，將外來鍵改為某個預設值 否則只要直接刪除/更新該筆值組即可 CH 5 資料庫

41 外來鍵參考對象的刪除/更新規則 －注意事項
不論採用何種做法，整個一連串的動作皆要看成一個異動(Transaction) 必須要全部做完，不然就全部都不做以維持一致性 以上四種做法在定義資料綱要就應該直接規範，若放在應用程式的執行邏輯較不好 CH 5 資料庫

42 Ensuring data integrity through updates
CH 5 資料庫

43 外來鍵參考對象的刪除/更新規則 － SQL Server 2000 的作法
操作： 進入關聯性（relationship）登入畫面 底下有一欄 Enforce relationship for INSERTs and UPDATEs 此項若不選，則所有”參考完整性”都不檢查了 此項若勾選，則再配合 □ Cascade Update Related Fields □ Cascade Delete Related Fields 此兩項若勾選，則為”連鎖反應作法”，否則為”限制性的作法” 那SQL Server 2005的作法？ CH 5 資料庫

44 行動主張（action assertion）
Action Assertions（行動主張）： Business rules：因應業務需要所訂定的規則限制 例如：修課規則限制 先修科目 上限學分 、最低學分 畢業學分 CH 5 資料庫

45 Well-Structured Relations （良好結構的關聯表）
定義： A relation that contains minimal data redundancy（最小資料重複）and allows users to insert, delete, and update rows without causing data inconsistencies（不會產生資料不一致） 包含最小冗餘程度的一種關聯表，讓使用者能新增、修改、刪除關聯表中的資料列，而不會導致資料的不一致 CH 5 資料庫

46 avoid anomalies（避免異常）
良好結構關聯表的目標是避免異常（ Goal is to avoid anomalies ）： Insertion Anomaly（新增異常）： adding new rows forces user to create duplicate data 加入新資料時強迫使用者要產生重複的資料 Deletion Anomaly（刪除異常）： deleting rows may cause a loss of data that would be needed for other future rows 刪除資料列後可能導致未來其他列會需要的資料跟著遺失 Modification Anomaly （修改新增異常）： changing data in a row forces changes to other rows because of duplication 因為資料有所重複﹐所以改變某資料列時﹐也強迫要改變其他列資料 CH 5 資料庫

47 異常（ anomalies ）的範例 －問題一 & 問題二
根據右列的EMPLOYEE2（Figure 5.2b） ： 問題一：Is this a relation? 答案： Yes unique rows and no multivalued attributes 每筆記錄皆唯一，且沒有多重值的欄位 問題二：What’s the primary key? 答案： Emp_ID, Course_Title CH 5 資料庫

48 異常（ anomalies ）的範例 －問題三
問題三：Anomalies in this Table Insertion： can’t enter a new employee without having the employee take a class 若某一員工尚未修讀任何一個課程，則無法新增該員工的資料 Deletion： if we remove employee 140, we lose information about the existence of a Tax Acc class 若刪除編號140 的員工資料，則連帶課程名稱為Tax Acc 的課程也會一併被刪除 因為這門課只有編號140員工修讀 Modification： giving a salary increase to employee 100 forces us to update multiple records 若要替編號100 的員工加薪，則所有與編號100 的員工有關記錄的薪水欄位都要一併修改 CH 5 資料庫

49 為何EMPLOYEE2不是良好結構的關聯表？
Why do these anomalies exist? （為何這些異常現象存在） 答案： Because we’ve combined two themes (entity types) into one relation. This results in duplication, and an unnecessary dependency between the entities 因為EMPLOYEE2將二個實體併為一個表格，導致資料重複存放與不需要的依存關係存在 經驗法則：一個表格不應該與一個以上的實體類型有關 CH 5 資料庫

50 將 EER 圖轉換成關聯表 邏輯資料庫設計： 以下我們以7 個步驟分別來說明如何將EER 圖轉換成關聯表
CH 5 資料庫

51 步驟一：對應一般實體到關聯表 （ Mapping Regular Entities to Relations ）
分成三類： 單一屬性：將E-R屬性直接對應到關聯表 複合屬性：只使用其中的單一成份屬性 多值屬性：另外產生個別的關聯表﹐且將原本實體的主鍵屬性當作外來鍵 CH 5 資料庫

52 步驟一：對應一般實體到關聯表 －1. 單一屬性 Simple attributes（單一屬性）:
E-R attributes map directly onto the relation 單一屬性直接轉換成關聯表的欄位 如：Fig. 5-8:對應一般實體（Mapping a regular entity） CUSTOMER entity type with simple attributes CUSTOMER relation： customer ( customer_id, customer_name, customer_address) CH 5 資料庫

53 步驟一：對應一般實體到關聯表 －2. 複合屬性 Composite attributes（複合屬性）:
Use only their simple, component attributes 複合屬性將其組成元素轉換成關聯表的欄位 如：Fig. 5-9:對應複合屬性（ Mapping a composite attribute ） (a) CUSTOMER entity type with composite attribute (b) CUSTOMER relation with address detail： customer ( customer_id, customer_name, street, city, state, zip ) CH 5 資料庫

54 步驟一：對應一般實體到關聯表 －3. 多重值屬性
Multi-valued Attribute（多重值屬性）： Becomes a separate relation with a foreign key taken from the superior entity. 多重值屬性必須新增一關聯表格，其主鍵來自其原來的關聯表主鍵，亦即其主鍵為一外來鍵 如：Fig. 5-10:對應含多重值屬性的實體（Mapping a multivalued attribute） Employee ( employee_id, employee_name, employee_address ) Employee_skill ( employee_id, skill ) 1 – to – many relationship between original entity and new relation CH 5 資料庫

55 步驟二：對應弱勢實體 （ Mapping Weak Entities ）
Becomes a separate relation with a foreign key taken from the superior entity 變成個別的關聯表﹐其主鍵（兼外來鍵）來自於與其相關強勢實體 Primary key composed of:（弱勢實體主鍵的組成） Partial identifier of weak entity（弱勢實體本身的部分識別子） Primary key of identifying relation (strong entity)（強勢實體的主鍵） CH 5 資料庫

56 步驟二：對應弱勢實體的範例 例如：Fig. 5-11: Example of mapping a weak entity
(a) Weak entity DEPENDENT Employee ( employee_id, employee_name ) Dependent ( employee_id, first_name, middle_initial, last_name， date_of_birth, gender) Dependent 的employee_id是外來鍵，參考到Employee 的employee_id主鍵 CH 5 資料庫

57 步驟二：對應弱勢實體的範例（續） 註： 如果DEPENDENT是個弱勢實體﹐則外來鍵的值域限制將不允許它為null值 外來鍵 複合主鍵
CH 5 資料庫

58 步驟三：對應二元關係 （Mapping Binary Relationships ）
一對多： 單基數邊上的主鍵變成多基數邊上的外來鍵 多對多 ： 產生一個新關聯表﹐而且以兩個實體的主鍵當作它的主鍵 一對一： 強制性邊的主鍵變成選擇性邊的外來鍵 CH 5 資料庫

59 步驟三：對應二元關係（Mapping Binary Relationships ） －1. 一對多（ One-to-Many）
Primary key on the one side becomes a foreign key on the many side 形成 2 個關聯表 且將 ‘1’ 那一方的主鍵複製到 ‘多’的那一方，變成‘多’的那一方的一個外來鍵參考 CH 5 資料庫

60 步驟三：對應二元關係 － 1. 一對多的範例 例如：Fig. 5-12: Example of mapping a 1:M relationship Relationship between customers and orders Mapping the relationship customer ( customer_id, customer_name, customer_address ) order ( order_id, order_date, customer_id ) 強制性的 單基數 CH 5 資料庫

61 步驟三：對應二元關係 － 1. 一對多的範例（續）
注意： no null value in the foreign key 此處外來鍵 customer_id 不能為 null，因為customer 為 mandatory minimum cardinality（強制性最小基數） CH 5 資料庫

62 步驟三：對應二元關係 － 2.多對多（Many-to-Many）
Create a new relation with the primary keys of the two entities as its primary key 必須多新增一個獨立關聯表 總共產生 3 個關聯表 此獨立表格其主鍵為一複合鍵，由所參與的所有關聯表的主鍵所組成 此獨立表格其主鍵的每個屬性皆是外來鍵，且參考到某個參與此關係關聯表的主鍵 CH 5 資料庫

63 步驟三：對應二元關係 － 2.多對多的範例 例如：Fig. 5-13: Example of mapping an M:N relationship ER diagram (M:N) 多對多關係的Supplies， 需另外成為一個新的關聯表，three resulting relations raw_materials ( material_id, unit_of_measure, standard_cost ) vendor ( vender_id, vendor_name, vendor_address ) quote ( material_id, vender_id, unit_price) CH 5 資料庫

64 步驟三：對應二元關係 － 2.多對多的範例（續）
複合主鍵 外來鍵 CH 5 資料庫

65 步驟三：對應二元關係 － 3. 一對一（One-to-One）
Primary key on the mandatory side（至少有一個） becomes a foreign key on the optional side（最少可為 0 個） 形成 2 個關聯表 且將 ‘至少有一個 ’ 那一方的主鍵複製到另一個 ‘最少可為 0 個’ 的一方，變成‘最少可為 0 個’ 的一方的一個外來鍵參考 CH 5 資料庫

66 步驟三：對應二元關係 － 3. 一對一的範例 例如：Fig. 5-14: Mapping a binary 1:1 relationship
(b) Resulting relations nurse ( nurse_id, name, date_of_birth ) care_center ( center_name, location, nurse_id, data_assign ) CH 5 資料庫

67 步驟四：對應聯合實體 （ Mapping Associative Entities ）
Identifier Not Assigned （聯合實體－本身沒有主鍵）： Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship) 聯合實體的主鍵由相關聯兩邊的實體主鍵組合而成 Identifier Assigned（聯合實體－本身有主鍵）： It is natural and familiar to end-users 直接使用本身的主鍵 Default identifier may not be unique 但有時候本身的主鍵可能不唯一 CH 5 資料庫

68 步驟四：對應聯合實體 －1. 本身沒有主鍵的範例
步驟四：對應聯合實體 －1. 本身沒有主鍵的範例 例如：Fig.5-15: Mapping an associative entity (a) Associative entity（聯合實體－本身沒有主鍵） Product Order_line Product_description Product_id order Standard_price Order-ID Order_date Product_finish Quantity CH 5 資料庫

69 步驟四：對應聯合實體 －1. 本身沒有主鍵的範例（續）
步驟四：對應聯合實體 －1. 本身沒有主鍵的範例（續） (b) Three resulting relations： order ( order_id, order_date ) product ( product_id, product_description, product_finish, standard_price ) order_line ( order_id, product_id, quantity ) CH 5 資料庫

70 步驟四：對應聯合實體 －2. 本身有主鍵 的範例 例如：Fig. 5-16: Mapping an associative entity
步驟四：對應聯合實體 －2. 本身有主鍵 的範例 例如：Fig. 5-16: Mapping an associative entity (a) Associative entity（聯合實體－本身有主鍵） CH 5 資料庫

71 步驟四：對應聯合實體 －2. 本身有主鍵 的範例（續）
步驟四：對應聯合實體 －2. 本身有主鍵 的範例（續） (b) Three resulting relations customer ( customer_id, name ) vendor ( vendor_id, address ) shipment ( shipment_no, customer_id, vendor_id , date, amount) CH 5 資料庫

72 步驟五：對應一元關係 （ Mapping Unary Relationships ）
One-to-Many（一對多）： 形成一個關聯表（ relation） Recursive（遞迴） foreign key in the same relation 同一個關聯表中的遞迴式外來鍵 Many-to-Many（多對多）： 形成兩個關聯表（ relations） One for the entity type 一個對應到實體類型 One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity 一個對應到聯合關聯表﹐其主鍵有2個屬性﹐都來自於該實體類型的主鍵 CH 5 資料庫

73 步驟五：對應一元關係 －1. 一對多範例 例如：Fig. 5-17: Mapping a unary 1:N relationship
Employee ( employee_id, name, birthdate, manager_id ) CH 5 資料庫

74 步驟五：對應一元關係 －2.多對多範例 (b) ITEM and COMPONENT relations
例如：Fig. 5-18: Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations item ( item_id, name, unit_cost ) component ( component_id , item_id , quantity ) CH 5 資料庫

75 步驟五：對應一元關係 －2. 多對多範例（續） (a) 材料表關係 (M:N) (b) ITEM與 COMPONENT 關聯表 CH 5
資料庫

76 步驟六：對應三元或多元關係 （ Mapping Ternary (and n-ary) Relationships ）
three for each entity type One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity 每個實體對應一個關聯表﹐而聯合實體也對應一個關聯表 聯合實體有外來鍵對應到關係中的每個實體 CH 5 資料庫

77 步驟六：對應三元或多元關係範例 例如：Figure 5-19: Mapping a ternary relationship
(a) Ternary relationship with associative entity CH 5 資料庫

78 步驟六：對應三元或多元關係範例（續） 轉成4 個關聯表（ relations）：
patient ( patient_id, patient_name ) physician ( physician_id, physician_name ) treatment ( treatment_code, description) Patient_treatment ( patient_id, physician_id, treatment_code, date, time, result ) CH 5 資料庫

79 步驟六：對應三元或多元關係範例（續） 注意： 主鍵必須是唯一的 CH 5 資料庫

80 步驟七：對應超類型/子類型關係 （Mapping Supertype/Subtype Relationships）
One relation for supertype and for each subtype 超類型對應至一個關聯表﹐子類型對應至一個關聯表 Supertype attributes（超類型的屬性）： including identifier and subtype discriminator go into supertype relation 納入超類型的屬性 (包括識別子與子類型鑑別子) 到超類型關聯表 Subtype attributes （子類型的屬性） ： primary key of supertype relation also becomes primary key of subtype relation 納入子類型屬性到每個子類型關聯表；而超類型關聯表的主鍵也會變成子類型關聯表的主鍵 1:1 relationship established between supertype and each subtype, with supertype as primary table 在超類型與每個子類型之間建立 1:1 關係﹐並以超類型為主要表格 CH 5 資料庫

81 步驟七：對應超類型/子類型關係範例 例如：Fig. 5-20: Supertype/subtype relationships CH 5
資料庫

82 步驟七：對應超類型/子類型關係範例（續）
Fig. 5-21: Mapping Supertype/subtype relationships to relations 轉成 4 個關聯表： employee ( Employee_number, employee_name, address, employee_type, date_hired ) P.S. 其中 employee_type 為子類型鑑別子 hourly ( H_Employee_number, hourly_rate ) salaried (S_Employee_number, annual_salary, stock_options ) consultant (C_Employee_number, contract_number, billing_rate ) CH 5 資料庫

83 步驟七：對應超類型/子類型關係範例（續）
CH 5 資料庫