第六章 結構化分析與設計： 資料塑模 (上) 一、資料塑模工具︰實體關係圖 二、實體關係圖之建構 三、實體關係圖轉關聯表 四、正規化

Presentation on theme: "第六章 結構化分析與設計： 資料塑模 (上) 一、資料塑模工具︰實體關係圖 二、實體關係圖之建構 三、實體關係圖轉關聯表 四、正規化"— Presentation transcript:

1 第六章 結構化分析與設計： 資料塑模 (上) 一、資料塑模工具︰實體關係圖 二、實體關係圖之建構 三、實體關係圖轉關聯表 四、正規化
第六章 結構化分析與設計： 資料塑模 (上) 一、資料塑模工具︰實體關係圖 二、實體關係圖之建構 三、實體關係圖轉關聯表 四、正規化 五、結構化企業資料塑模個案

2 一、資料塑模工具 導論 表單(form) 關聯式資料庫 包含大部分辦公室之資料處理活動 具有結構化、通用、正式、穩定等特性
缺點；造成重複及貯存成本→改採資料庫 關聯式資料庫 實體關係模式(Entity-relationship Model (E-R Model)是關聯式資料庫設計的重要工具之一 實體關係圖(Entity-relationship Diagram, ERD)是 E-R Model的一種圖形表示

3 實體關係圖(ERD) 組成元素： 矩形：實體類型(Entity Type) 菱形：實體類型間的關係 (Relationship)
橢圓：實體類型或關係之屬性(Attribute) 直線：把屬性連結到實體類型，或把實體類型連結到關係 基數(Cardinality)：代表實體類型間之關係程度，可以是一對一、一對多(或多對一)或者多對多。

4 ERD範例 訂貨 訂單 產品 訂單與產品為實體，訂貨則為這兩個實體之關係 訂單編號及客戶編號為訂單之屬性
訂購數量 產品編號 單價 訂貨 M N 訂單 產品 訂單與產品為實體，訂貨則為這兩個實體之關係 訂單編號及客戶編號為訂單之屬性 訂單與產品發生的訂貨關係之基數為M:N(多對多) N表示每張訂單可訂購N個(多個)產品，而M表示每個產品可以出現於M張訂單中，因數目不限故以M或N泛稱。

5 實體關係圖 內容大綱 實體類型 屬性 多值屬性 準鍵與主鍵 關係 關係基數 關係度

6 1.1 實體類型 涵意 一些具有共同性質或特徵之實體案例 (Entity instance)的集合。
以矩形表示，且有一個名稱為其辨別物(Identifier)標示於矩形內。 實體之種類很多，主要包括人、地方、物件、事件或使用者環境中之概念等。 員工

7 1.2 屬性 涵意 屬性是實體類型的一個性質或特徵 以橢圓形表示，需有一名稱以茲辨別並標示於橢圓形中，且以線條與其實體相連接。學生實體類型及其屬性實例︰ 學號 姓名 地址 電話 學生

8 1.2.1 多值屬性 Multivalued Attributes 指一個實體的某個屬性有一個以上之值
例如︰眷屬是員工(實體)的屬性之一，其眷屬資料為眷屬姓名、年齡與關係(配偶、孩子、父母等)，因一員工可能有多個眷屬，故眷屬是多值屬性。 兩種常用的多值屬性表示法： 用雙線的橢圖形表示 用弱(week)實體類型表示︰以另一實體來表示，並以線條與原實體相連

9 以雙線橢圓形表示多值屬性 以弱實體類型表示多值屬性 員工 員工 眷屬 員工代號 眷屬姓名, 眷屬年齡, 眷屬關係 員工代號 眷屬姓名
N 眷屬

10 1.2.2 準鍵與主鍵 準鍵 (Candidate Key)或候選鍵 主鍵(Primary Key)
是一個屬性或多個屬性的集合，它(們)可用來區別實體類型的每個實體案例。 例如︰員工可能的準鍵為(1)員工代號；(2)員工姓名+地址(假設同個地址不會住著兩個以上同名同姓的人) 主鍵(Primary Key) 準鍵之一，用以區別實體類型中之案例 常以底線表示之

11 主鍵之選用準則 (Bruce, 1992) 其值在每個案例的生命過程中不會改變 需是有效值，且不可為空值(Null)
例如用地址與名字當做員工主鍵並不恰當，因為員工之地址可能會改變。 需是有效值，且不可為空值(Null) 避免使用智慧鍵(Intelligent Keys) 智慧鍵︰該鍵之結構表示分類或位置等 例如若員工實體之主鍵前兩碼表示部門，則員工調至其他部門，或組織結構改變，主鍵將需經常修改 以單一屬性主鍵代替多個屬性的組合鍵

12 1.3 關係 涵意 一個或多個實體類型的案例間之關聯(Association)，經常意味著事件已發生或存在一些案例間自然的連結。 1.3.1關係基數 指實體類型(如電影)之案例與另一實體類型(如錄影帶)之案例的關聯數目 1 N 電影 被存成 錄影帶

13 最小基數與最大基數 實體案例間之關聯數目若有限制 若有最小之限制，稱為最小基數 若有最大之限制，稱為最大基數
選擇性的參與者(Optional participant)；關係的最小基數為０之實體類型，如錄影帶 強制性的參與者(Mandatory participant)；關係的最小基數為１之實體類型 若有最大之限制，稱為最大基數 1 [0,N] 電影 被存成 錄影帶

14 1.3.2 關係度 degree of a relationship 指參與在某個關係中之實體類型的數量
在 E-R 模式中，三種最常見之關係度： 單一(Unary, degree one)關係 二元(Binary, degree two)關係 三元(Ternary, degree three)關係

15 (1)單一關係 又稱遞迴關係(Recursive Relationship)，此關係是建立在一實體類型之案例間 一對一之單一關係實例
一個人(案例)可以和另一個人(案例)有一對一的婚姻關係 人 結婚 1 N 一對多之單一關係實例 一個主管(員工案例)可以管理多個下屬(員工案例) 員工 管理 1

16 (2)二元關係 表示兩個實體類型其案例間之關係，此種關係最為常見 一對多之二元關係實例 多對多之二元關係實例 生產線 包含 產品 學生 選修
一條生產線可生產N個產品，而一個產品僅屬於某條生產線 1 N 生產線 包含 產品 多對多之二元關係實例 一個學生可選修N個課程，而一個課程可被M個學生所選修 M N 學生 選修 課程

17 (3)三元關係 表示三個實體類型其案例間之共同關係 如零件、供應商與批發商均是實體，三者間有「輪船運送」之關係，且數量為屬性
某供應商以輪船運送某些數量之零件給某些批發商→三個實體才能共同決定運送之數量 零件 N N 輪船運送 N 供應商 批發商 數量

18 二、實體關係圖之建構 建立ERD可依以下三階段進行： 確認實體及其屬性→實體屬性表 確認實體間關係與基數→實體關係矩陣 確認實體關係之屬性
整合原則與一般化原則 確認實體、確認屬性 確認實體間關係與基數→實體關係矩陣 確認關係、確認基數 確認實體關係之屬性

19 2.1 確認實體及其屬性 整合(aggregation)原則 將一些描述某物件或概念基本性質之項目加以結合，以形成一個較高階之物件或概念
此物件或概念稱為實體，而描述該實體基本性質的項目為其屬性 例如著作名稱、編號、作者、館藏、出版日期等項目都可視為是描述 「書」之物件的基本性質，這些項目可被整合成一實體稱為「書」，而這些項目是書之屬性。

20 一般化(generalization)原則
將一些具有某些性質之項目集合起來，並抽象化成較高層次之概念 例如轎車、卡車、小貨車等項目，可被集合起來，抽象化成汽車之類型 汽車類型為實體 轎車、卡車、小貨車是該實體的子集合

21 2.1.1 確認實體 分析之資料與原則 實體確認可由需求分析階段之藍圖及其資料辭彙找起 檢查每個項目或欄位
aggregation︰將描述相同物件或概念之 屬性整合成一實體 generalization︰將一些具有某性質之項目集合，然後一般化成一實體

22 分辨藍圖中可能實體的經驗法則 (1)通常原始表單本身就是一個實體 (2)一些描述某物件或概念的基本性質之項目可能被整合成一實體
例如請購單即為一個「請購單」實體 (2)一些描述某物件或概念的基本性質之項目可能被整合成一實體 表單欄位若為一相關聯的群組(Group) 例如「請購單」中的明細資料，包括產品編號、品名、規格與單位等項目是一相關聯的群組，可形成一個「產品」實體 格式欄位有共同字首的

23 請購單 訂購單

24 分辨藍圖中可能實體的經驗法則(續) (3)表單欄位若為一般認定的關鍵詞(如姓名)，則可能為一實體
例如「訂購單」中的經手人及廠商名稱，可能形成「員工」與「供應商」實體。 (4)若某表單為另一表單欄位的來源，則此表單可能為一實體 如「訂購單」的請購單編號，來自「請購單」，故「請購單」應自成一實體。

25 2.1.2 確認屬性 分辨出表單中可能的實體後，可採經驗法則確認每個實體的屬性：
(1)以相關聯群組形成的實體，其相關聯群組所包含的欄位皆為其屬性 例如「請購單」中的明細資料(包括產品編號、品名、規格與單位)形成「產品」實體，故這些明細資料均為該實體之屬性

26 (2)若一個表單欄位的來源直接參照其他實體之屬性，則這些屬性不需重複出現
如「請購單」其產品相關之欄位已形成「產品實體」之屬性，故只需包含請購日期、請購人、製單、請購單編號、需求日期等屬性。 (3)表單欄位與之前確認的實體間位置距離相近者，亦可能形成該實體之屬性 因人們設計表單時，常將相關的項目放在一起 例如「請購單」之請購日期、請購人、製單、請購單編號、需求日期等，為「請購單」實體之屬性。

27 實體屬性表範例 利用此表記錄實體與屬性，有助於不同表單可能產生相同實體之整合

28 2.2 確認實體間關係與基數 2.2.1 確認關係 (1)若一表單為另一表單欄位的參考來源，則兩表單分別形成的實體應有關係存在
如「請購單」的請購單編號是「訂購單」的參考來源，故兩實體間有一「申請」的關係 (2)若一實體是由表單中一個關聯的群組所形成，則該實體和原表單間應形成關係 如「請購單」的產品明細資料獨立形成一個產品實體，所以產品和請購單間有一關係

29 2.2.2 確認基數 形成實體間之關係後，需判斷各關係之基數： (1)若一表單中含有多筆資料參考到另一表單，則其關係可能為1：N或M：N
(3)配合企業規則判斷

30 實體關係矩陣 利用此矩陣可分析實體間之關係，便於畫出ERD 畫一矩陣，將實體分別置於縱軸與橫軸 分析實體間關係之基數，置於矩陣格子內
由於矩陣對稱，因此僅表示右上角即可

31 2.3 確認實體關係之屬性 有些屬性並不單獨屬於任一實體，而是屬於某些實體之關係
實例︰訂單與產品兩個實體中，假設某企業之經營規則對產品之價格可能並不是固定的，而是依訂貨數量而定 產品價格不單獨屬於訂單或產品 N 訂購 N 訂單 產品 訂貨數量 產品價格