F、結構化分析與設計： 資料塑模(I) 資料塑模工具︰實體關係圖 實體關係圖之建構 實體關係圖轉關聯表 正規化 關聯表資料字典

Presentation on theme: "F、結構化分析與設計： 資料塑模(I) 資料塑模工具︰實體關係圖 實體關係圖之建構 實體關係圖轉關聯表 正規化 關聯表資料字典"— Presentation transcript:

1 F、結構化分析與設計： 資料塑模(I) 資料塑模工具︰實體關係圖 實體關係圖之建構 實體關係圖轉關聯表 正規化 關聯表資料字典
實體類型、屬性、關係 實體關係圖之建構 確認實體及其屬性 確認實體間關係與基數 確認實體關係之屬性 實體關係圖轉關聯表 七個轉換規則 正規化 涵義與資料異常、相依、正規化實務 關聯表資料字典

2 1. 資料塑模工具 實體關係模式(Entity-relationship Model (E-R Model)是關聯式資料庫設計的重要工具之一
實體關係圖(Entity-relationship Diagram, ERD)是 E-R Model的一種圖形表示

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

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

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

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)，經常意味著事件已發生或存在一些案例間自然的連結。 關係基數 關係度

13 1.3.1 關係基數 指實體類型(如電影)之案例與另一實體類型(如錄影帶)之案例的關聯數目 最小基數與最大基數：實體案例間之關聯數目若有限制
若有最小之限制，稱為最小基數 選擇性的參與者(Optional participant)：關係的最小基數為０之實體類型，如錄影帶 強制性的參與者(Mandatory participant)：關係的最小基數為１之實體類型 若有最大之限制，稱為最大基數 電影 被存成 1 錄影帶 N 電影 被存成 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 2. 實體關係圖之建構 建立ERD可依以下三階段進行： 確認實體及其屬性→實體屬性表 確認實體間關係與基數→實體關係矩陣 確認實體關係之屬性
整合原則與一般化原則 確認實體、確認屬性 確認實體間關係與基數→實體關係矩陣 確認關係、確認基數 確認實體關係之屬性

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

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

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

22 分辨藍圖中可能實體的經驗法則 (1) 通常原始表單本身就是一個實體 例如請購單即為一個「請購單」實體

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

24 分辨藍圖中可能實體的經驗法則 (Cont.)
(3) 表單欄位若為一般認定的關鍵詞(如姓名)，則可能為一實體 例如「訂購單」中的經手人及廠商名稱，可能形成「員工」與「供應商」實體。

25 分辨藍圖中可能實體的經驗法則 (Cont.)
(4) 若某表單為另一表單欄位的來源，則此表單可能為一實體 如「訂購單」的請購單編號，來自「請購單」，故「請購單」應自成一實體。

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

27 確認屬性 (Cont.) (2) 若一個表單欄位的來源直接參照其他實體之屬性，則這些屬性不需重複出現
如「請購單」其產品相關之欄位已形成「產品實體」之屬性，故只需包含請購日期、請購人、製單、請購單編號、需求日期等屬性。

28 確認屬性 (Cont.) (3) 表單欄位與之前確認的實體間位置距離相近者，亦可能形成該實體之屬性 因人們設計表單時，常將相關的項目放在一起
例如「請購單」之請購日期、請購人、製單、請購單編號、需求日期等，為「請購單」實體之屬性。

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

30 2.2 確認實體間關係與基數 2.2.1 確認關係 (1) 若一表單為另一表單欄位的參考來源，則兩表單分別形成的實體應有關係存在
如「請購單」的請購單編號是「訂購單」的參考來源，故兩實體間有一「申請」的關係

31 2.2.1 確認關係 (Cont.) (2) 若一實體是由表單中一個關聯的群組所形成，則該實體和原表單間應形成關係
如「請購單」的產品明細資料獨立形成一個產品實體，所以產品和請購單間有一關係

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

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

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

35 註︰關係連到實體若為雙線，表示完全參與關係，即實體之所有案例均有對應
3. 實體關係圖轉關聯表 當一個E-R Model建立後，可根據7個轉換規則，將ERD轉成關聯表 (Relation;Table) ERD範例 部門編號 部門名稱 部門地點 員工姓名 1 員工薪水 工作 部門 1 員工編號 員工地址 N 1 1 控制 管理 員工 M N 開始日期 1 N 專案 親屬 負責 眷屬姓名 N 專案編號 專案名稱 工作時數 眷屬 眷屬關係 註︰關係連到實體若為雙線，表示完全參與關係，即實體之所有案例均有對應

36 3.1 步驟一 對每個一般性實體建立一個關聯表 屬性︰該實體所有屬性 主鍵︰根據主鍵選取原則， 從準鍵中選擇一個主鍵 以「員工」 實體為例
主鍵︰根據主鍵選取原則， 從準鍵中選擇一個主鍵 以「員工」 實體為例 該實體可被轉成一關聯表 原來實體上之屬性為該關聯表之屬性 可選擇員工編號屬性做為主鍵 員工關聯表： 員工姓名 員工薪水 員工編號 員工地址 員工 員工編號 員工姓名 員工地址 員工薪水

37 3.2 步驟二 對每個弱實體類型建立一個關聯表 屬性︰該實體所有屬性+擁有者實體主鍵 主鍵︰擁有者實體主鍵+弱實體不完全鍵
以「眷屬」 實體為例 眷屬關聯表： 員工姓名 員工薪水 眷屬姓名 眷屬關係 員工編號 員工地址 1 N 員工 親屬 眷屬 員工編號 眷屬姓名 眷屬關係

38 3.3 步驟三 對每個多值屬性建立一個關聯表 屬性︰該多值屬性+擁有者實體主鍵 主鍵︰該關聯表所有屬性 以「部門地點」之多值屬性為例
部門地點關聯表： 部門編號 部門名稱 部門地點 部門 部門編號 部門地點

39 3.4 步驟四 對每個M:N(多對多關係)建立一關聯表 屬性︰該關係所有屬性+兩實體主鍵 主鍵︰兩外鍵(foreign key)之集合
以「員工」及「專案」兩 實體之「負責」關係為例 負責關聯表： 員工姓名 員工薪水 工作時數 專案編號 專案名稱 員工編號 員工地址 M N 員工 負責 專案 員工編號 專案編號 工作時數

40 3.5 步驟五 對每個1:1(一對一關係)之處理 具完全關係的實體為S端，另一端為R端，對S端之關聯表進行擴充(不產生新關聯表)
以「員工」及「部門」的「管理」關係為例 部門關聯表： 員工 員工編號 員工姓名 員工地址 員工薪水 管理 1 部門 部門編號 部門名稱 部門地點 開始日期 註︰每個部門都有管理者； 並不是每個員工都擔任主管 部門編號 部門名稱 開始日期 員工編號

41 3.6 步驟六 對每個1:N(一對多關係)之處理 對N端之關聯表進行擴充(不產生新關聯表) 以「員工」及「部門」的「工作」關係為例
員工關聯表： 員工 員工編號 員工姓名 員工地址 員工薪水 工作 N 1 部門 部門編號 部門名稱 部門地點 員工編號 員工姓名 員工地址 員工薪水 部門編號

42 3.7 步驟七 對每個N元關係建立一個關聯表 每個N元(N3)關係都轉換為一個關聯表 以下圖之「供應」三元關係為例
屬性︰該關係所有屬性+所有參與實體的主鍵 主鍵︰所有外鍵 以下圖之「供應」三元關係為例 供應關聯表： 供應商 供應商編號 供應 專案 專案編號 零件 零件編號 供應數量 供應商編號 零件編號 專案編號 供應數量