ER Model

2-1 塑模(Modeling)與模型(Model)

2-1 塑模(Modeling)與模型(Model) 目前較為通用的模型大致可分為三種模型 第一種是『處理為主』(Process Driven)的模型 例如較早期所使用的『資料流程圖』 (Data Flow Diagram，簡稱DFD) 第二種是以『資料為主』 (Data Driven)的模型 此種模型主要是以資料為主要考量方向的『實體關聯圖』 (Entity Relationship Diagram，簡稱ERD)，大部份是使用在資料庫的設計使用 第三種是以『物件導向』為主的模型(Object Oriented) 此模型的代表則為『統一塑模語言』(Unified Modeling Language，簡稱UML) 這三種模型所要代表和展現出來的意義皆有所不同，也就是所要描述的構面和目的會有所不同。

Data Flow Diagram 用來呈現“資料”在資訊系統裡面的流動 資料流 外部實體 資料儲存媒體 處理程序 實體資源流

ER Diagram 通常但並不限於關聯式資料庫所採用

UML Diagram 以“物件”為導向來描述系統

2-2 實體關聯圖 (Entity Relationship Diagram)

2-2 實體關聯圖 『實體關聯圖』(Entity Relationship Diagram) 以『資料』為主要考量方向的實體關聯模型

例如學生與課程之間會產生一種『選修』的關係；一位學生通常可選修多門課程；相反地，一門課程又可以被多位學生選修，此種『關係』又產生數量上所謂的『基數』(Cardinality)關係 『基數』關係一般可分為以下四種：  1：1 ：一對一關係 1：N ：一對多關係 M：1 ：多對一關係 M：N ：多對多關係

2-2 實體關聯圖 『學生』和『課程』之間的『選修』關係，圖中用N來表示出一位學生可以選多門課程；用M表示出一門課程可以被多位學生選修 此表示為M：N，此處的M與N都表示多的意思，即為多位學生對多門課程之意 而此處的學生和課程皆表示為一個實體(Entity)，而『選修』則為此兩者之間的『關係』(Relationship) 學生選課之資料模型

在資料庫管理系統當中，資料庫設計是相當重要的一環 倘若設計不當，最後所設計出來的資料庫系統，絕對會是一個失敗的專案，更會導致企業流程混亂而無所適從，甚至產生出錯誤的資訊，造成企業決策者的誤判，更別說要利用資料庫系統來提升企業競爭力或改善企業流程

2-3 資料的抽象化

2-3 資料的抽象化 【定義】 將不同事物之共同特性歸納或抽離出來，並整理成另一個事物或一個概念的過程，稱之為『抽象化』 (Abstract)或『一般化』 (Generalize)。反之，則稱為『具體化』(Specialize)。

2-3 資料的抽象化 資料抽象化之範例 例如我們在公司上班，會有許多不同職務主管和員工，例如 員工代號581，名字為Candy住Tainan 員工代號854，名字為Andy住Taipei 員工代號542，名字為Jacky住Taipei

2-3 資料的抽象化 資料抽象化之範例 例如我們在公司上班，會有許多不同職務主管和員工，例如 員工代號581，名字為Candy住Tainan 員工代號854，名字為Andy住Taipei 員工代號542，名字為Jacky住Taipei 此三名員工為三個獨立或特定的實體(Entity)將共同的屬性抽離出 來，這就是所謂的抽象化過程，抽象後所形成的實體型態(Entity Type)，我們將之表示成： 員工(員工代號、姓名、住址) 『實體型態名稱』(Entity Type Name) ：『員工』 員工實體型態之『屬性』(Attribute)：『員工代號』、『姓名』及『住址』 姓名屬性之『屬性值』(Attribute Value)： Candy、Andy及Jacky

資料抽象化範例之圖示 三個員工實體 經過抽象化的 員工實體型態 抽 象 化 三個員工實體 資料的抽象化 員工 員工代號 姓名 住址 員工 按任意鍵 --- 繼續 --- 抽　象　化 三個員工實體 員工 員工代號 姓名 住址 581 Candy Tainan 854 Andy Taipei 542 Jacky 按任意鍵 --- 繼續 --- 資料的抽象化 581 854 542 Candy Andy Jacky Tainan Taipei

2-4 資料模型的重要性

不當設計所產生的問題 不當的資料設計，where’s the problem? 訂單資料 訂單編號 訂購日期 客戶 地址 產品 數量 單價 00001 2006/01/12 陳如鷹 台北 紅茶 90 8 綠茶 120 7 陳如鶯 咖啡 105 15 00002 2006/02/11 蔡育倫 嘉義 160 14 不當的資料設計，where’s the problem?

不當設計所產生的問題 鷹？ 鶯？ 不當的資料設計 訂單資料 訂單編號 訂購日期 客戶 地址 產品 數量 單價 00001 2006/01/12 陳如鷹 台北 紅茶 90 8 綠茶 120 7 陳如鶯 咖啡 105 15 00002 2006/02/11 蔡育倫 嘉義 160 14 不當的資料設計 鶯？

適當設計後的情形，分割資料表 訂單 訂單明細 一對多 改變後的資料 (a) 切割後的資料表 訂單 訂單編號 訂購日期 客戶 地址 00001 2006/01/12 陳如鷹 台北 00002 2006/02/11 蔡育倫 嘉義 訂單明細 訂單編號 產品 數量 單價 00001 紅茶 90 8 綠茶 120 7 咖啡 105 15 00002 160 14 一對多 改變後的資料 (a) 切割後的資料表

訂單表單中的思維 訂 單 訂單編號： 00001 訂購日期： 2006/01/12 客戶： 陳如鷹 地址： 台北 貨品明細 一 筆 訂單 訂　單 訂單編號： 00001 訂購日期： 2006/01/12 客戶： 陳如鷹 地址： 台北 貨品明細 一 筆 訂單 對應 序號 產品 數量 單價 1 紅茶 90 8 2 綠茶 120 7 3 咖啡 105 15 4 5 多 筆 訂單明細 改變後的資料 (b) 訂單之表單

2-5 概念實體關聯模型基本認識

『概念』與『實體』資料模型的轉換 溝通 程式 規格書 系統分析師 企業客戶 程式設計師 概念資 料模型 實體資 料模型 模型轉換 按任意鍵 --- 繼續 --- 概念資 料模型 實體資 料模型 模型轉換 概念資料模型與實體資料模型的轉換關係

2-5 概念實體關聯模型基本認識 實體(Entity) 實體集合(Entity Set) 屬性(Attribute) 屬性值 (Attribute Value)

實體 實實在在的物體 在真實世界中，代表著獨立、具體且特定的一個人、事、時、地、物或只是一個概念上的任何事物 例如在某家公司上班的五位員工，每一位員工都算是一個獨立、具體的實體 員工(8210171，胡琪偉，33，1963/8/12，{94010301、94010601}，220 台北縣板橋市中山路一段) 員工(8307021，吳志梁，35，1960/5/19，94010701，Null) 員工(8308271，林美滿，38，1958/2/9，{94010105、94010201、94010302、94010303、94010702}，104台北市中山區 一江街) 員工(8311051，劉嘉雯，28，{1968/2/7，94010101、94010106、94010808}，111台北市士林區福志路) 員工(8312261，張懷甫，27，1969/1/2，Null，220台北縣板橋市五權街32巷)

實體與屬性 實體 名稱 屬性 實體 型態 員工 員工編號 姓名 年齡 出生日期 訂單編號 地址 8210171 胡琪偉 33 1963/8/12 94010301 94010601 220台北縣板橋市中山路一段 8307021 吳志梁 35 1960/5/19 94010701 (Null) 8308271 林美滿 38 1958/2/9 94010105 94010201 94010302 94010303 94010702 104台北市中山區 一江街 8311051 劉嘉雯 28 1968/2/7 94010101 94010106 94010808 111台北市士林區福志路 8312261 張懷甫 27 1969/1/2 220台北縣板橋市五權街32巷 實體集合 實體 實體與屬性

相關定義 【定義】在真實世界中，『實體』(Entity)代表著一個獨立、具體且特定的一個人、事、時、地、物或是一個概念上的事物。 【定義】具有相同屬性(Attributes)的實體所構成的集合，稱為『實體集合』(Entity Set)。 【定義】『屬性』(Attribute)就是用來定義或描述實體特性的一個表示項目；而每一個屬性都至少會具有一個或一個以上的值，稱為『屬性值』 (Attribute Value)。

不同類型的屬性 『鍵值屬性』 (Key Attribute) 『單值屬性』與『多重值屬性』 (Single-Valued & Multi-Valued) 『單元型屬性』與『複合型屬性』 (Atomic Attribute & Composite Attribute) 『儲存型屬性』與『衍生型屬性』 (Stored Attribute & Derived Attribute) 一個特殊的屬性值，稱為『空值』 (Null Value)。

『鍵值屬性』 在一個實體集合中，不希望在集合中出現兩個或兩個以上的實體是屬於相同的一個實體，也就是造成了資料的重複 唯一識別該實體的屬性 鍵值屬性能夠唯一識別該紀錄的屬性，所以 不可有重複值產生 不可有『空值』(Null Value)的情形

『單值屬性』與『多值屬性』 某項屬性會同時具有多個屬性值，稱為『多值屬性』 該屬性最多只會有一個值或是空值，稱為『單值屬性』 例如員工“胡琪偉”承接了兩筆訂單，訂單編號分別為94010301、94010601，此時的“訂單編號”的屬性即成為『多值屬性』(Multi-Valued Attribute) 並將以大括弧{}表示成{94010301、94010601} 該屬性最多只會有一個值或是空值，稱為『單值屬性』

『單元型屬性』與『複合型屬性』 單元型屬性 複合型屬性 一個屬性不能再被切割成更小的屬性 一個屬性可以再被切割成更小不同屬性的組合 例如“地址”屬性，可分為區域號碼、縣市、街道等等；而街道或許可以再分為路名、段、巷、弄、號、樓…等等，即為複合型屬性。

地址 區域號碼 縣市 街道 路(街)名 段 巷 弄 號 樓 複合型屬性

『儲存型屬性』與『衍生型屬性』 儲存型屬性 衍生型屬性 該屬性的值是必須被儲存下來的 由儲存型屬性，或是透過其他資料計算或推導出來的值 例如年齡，可藉由『目前日期』以及『出生日期』相互計算得之 『衍生型屬性』的儲存值是否不被儲存於儲存體或資料庫，可視必要性來決定

『空值』 (Null Value) 『不適用』(Not Applicable) 『未知』(Unknown) 有些屬性不適合某些實體的使用 該屬性值是存在的，但由於某種情形，尚無法得知該實體的屬性值 該屬性值不知是否存在的情形下，也會暫將該屬性保持『空值』

實體型態(Entity Type) 相近或類似的實體，透過歸納(也就是透過前述的資料『抽象化』或『一般化』的概念)的方式，組合成一個所謂的『實體型態』(Entity Type)

實體型態(Entity Type) 相近或類似的實體，透過歸納(也就是透過前述的資料『抽象化』或『一般化』的概念)的方式，組合成一個所謂的『實體型態』(Entity Type) 一群的老師，可以將共同的屬性集合成一個稱為『老師』的實體型態；學校的職員，可另外形成一個稱為『職員』的實體型態，並將實體型態表示成以下方式： 老師(老師代號、姓名、聯絡地址、聯絡電話、科系、專長) 職員(職員代號、姓名、聯絡地址、聯絡電話、單位)

實體型態(Entity Type) 相近或類似的實體，透過歸納(也就是透過前述的資料『抽象化』或『一般化』的概念)的方式，組合成一個所謂的『實體型態』(Entity Type) 一群的老師，可以將共同的屬性集合成一個稱為『老師』的實體型態；學校的職員，可另外形成一個稱為『職員』的實體型態，並將實體型態表示成以下方式： 老師(老師代號、姓名、聯絡地址、聯絡電話、科系、專長) 職員(職員代號、姓名、聯絡地址、聯絡電話、單位) 以上的兩個實體型態在相較之下，或許會被認為同質性相當高，所以可以再利用前述的抽象概念，將兩者更一般化來處理，形成一個稱為『員工』的實體型態，另外產生一個『身份』的屬性來區分兩者之間的差異，如下： 員工(員工代號、姓名、聯絡地址、聯絡電話、部門、專長、身份)

實體型態(Entity Type) 【定義】 將數個性質相近的實體，彙整出共同的屬性及實體名稱，此稱為『實體型態』(Entity Type)

2-6 概念實體關聯模型及構成要素

2-6 概念實體關聯模型及構成要素 實體型態 關係、識別關係 屬性 基數關係 參與關係

實體型態 兩種實體型態 『強實體型態』 (Strong Entity Type) 『弱實體型態』 (Weak Entity Type)。 【定義】 具有『鍵值屬性』的實體，或是可以獨立存在，不需要依附在其他實體的實體，稱之為『強實體型態』 (Strong Entity Type)或簡稱『實體』。 不具有鍵值屬性的實體，或是無法獨立存在的實體，必須依附在其他實體才能存在的，稱之為『弱實體型態』 (Weak Entity Type)。 名稱 實體表示法 名稱 弱實體表示法

明細資料 訂購單 訂購明細

關係、識別關係 關係 識別關係 此關係代表兩個實體之間具有某種的互動 例如學生”選修”課程，說明了學生實體與課程之間為”選修”關係 通常表示成菱形，內部標示此關係的名稱 識別關係 弱實體型態，沒有鍵值屬性之外，也必須依附在另一個強實體型態 兩個實體之間的關係 兩者皆為強實體型態 不可能兩邊皆為弱實體型態 當其中有一個是弱實體型態時，由於沒有鍵值屬性，所以必須透過『識別關係』來做為弱實體的識別 名稱 名稱

明細資料 訂購單 訂購明細

屬性(1/3) 實體與屬性 關係與屬性 屬性通常是附加在實體之上 通常都是在實體上加上一條線，以及一個小橢圓形表示 當此關係的發生，有可能要記錄下某些資訊，而非僅僅在於概念的關係 例如員工與部門之間的『管理』關係，此關係必須記錄員工與部門之間的管理起、迄時間 名稱 屬性名稱 關係名稱 屬性名稱

屬性(2/3) 實體與衍生屬性 實體與鍵值屬性 由儲存型屬性或其他輸入資料所計算或推算出來的 必須標示出來，忠實記錄使用者的需求 使用虛線的橢圓形，內部標示該衍生屬性的名稱 實體與鍵值屬性 內部則為該鍵值屬性名稱 鍵值屬性名稱下方加上底線 名稱 屬性名稱 名稱 屬性名稱

屬性(3/3) 多值屬性 複合型屬性 可能沒有任何的屬性值，也有可能同時擁有多個屬性值 以兩個同心橢圓形來表示，內部標示出多值屬性的名稱 由多個屬性所組成的屬性 名稱 名稱 ...... 屬性名稱

基數關係 基數(Cardinality)關係所代表的是兩個實體E1與E2的比率關係 通常可分為下列四種情形： 1：1：一對一關係，表示兩實體之間是一個對應一個 1：N：一對多關係，表示一個左邊實體會對應到多個右邊實體 M：1：多對一關係，表示多個左邊實體會對應到一個右邊實體 M：N：多對多關係，表示多個左邊實體會對應到多個右邊實體 R E1 E2 1 N

參與關係 參與關係可分為 例如 『部份參與』 表示該實體型態中，有部份的實體會參與此關係，有些不參與 『全部參與』 表示該實體型態中，全部的實體都會參與此關係 例如 學生與監護人之間的關係，僅有未成年的學生才必須有監護人，反之，成年之學生並不需要有監護人。 所以在學生這邊的參與關係為『部份參與』關係，以一條直線表示之。反之，監護人一定會對應到學生，所以監護人這邊的參與關係為『全部參與』關係，以兩條直線表示之。 R E1 E2

參與關係 參與數的限制 學校選課時，每一門課程會因成本考量，會將學生選修人數做一最低人數方才開班的限制，以及受教室容量的大小限制，而限制學生選修的人數上限，此種即為『參與數的限制』關係 此種關係並不一定同時發生在實體雙方，所以在被限制的一端標示{min,max}的上、下限符號 R E {min,max}

表2-1實體關聯圖的基本要素說明(1/3) 序號 基本圖示 名 稱 說 明 1 實體型態 (Entity Type) 名　稱 說　明 1 實體型態 (Entity Type) 代表真實世界中，具體的人、事、時、地、物或是一個概念。例如員工或公司。 2 弱實體型態 (Weak Entity Type) 弱實體的存在，一定會相依於實體而存在。例如在公司員工的家屬，沒有員工的存在，就不會有家屬的存在。 3 屬性 (Attribute) 代表每一個實體型態所擁有的屬性。 4 衍生屬性 (Derived Attribute) 其值是經過計算出的屬性。例如員工的年齡，可透過出生日期屬性值計算出。 5 鍵值屬性 (Key Attribute) 代表此屬性為該實體型態的唯一識別之鍵值。 名稱 名稱

表2-1實體關聯圖的基本要素說明(2/3) R E1 E2 序號 基本圖示 名 稱 說 明 6 多值屬性 名　稱 說　明 6 多值屬性 (Multi-Valued Attribute) 代表此屬性在該實體型態中，具有多重的值。例如一個員工同時有多個電話，此電話屬性即為多值屬性。 7 複合屬性 (Composite Attribute) 複合屬性是由多個單一屬性所組合合成，例如地址屬性可由縣市、路名、…等等所組成 8 關係 (Relationship) 代表兩實體型態之間的互動關係。例如員工與專案之間是”負責關係”。 9 識別關係 (Identifying Relationship) 代表實體與弱實體之間的識別關係 10 基數 (Cardinality) 基數是代表兩實體型態E1和E2之間的比率關係。例如一位員工(E1)負責®N個專案(E2)。 ... R E1 E2 1 N

表2-1實體關聯圖的基本要素說明(3/3) R E1 E2 R E 序號 基本圖示 名 稱 說 明 11 全部參與 名　稱 說　明 11 全部參與 (Total Participation) 代表實體型態E2內所有的實體皆必須具有和E1有R的關係存在。 12 參與數的限制 (Constraint of Participation) 實體型態與關聯型態之間的比率關係。例如學生的實體型態與選課的關聯型態之間的比率關係。 R E1 E2 R E {min,max}

2-7 概念實體關聯模型的範例說明

2-7 概念實體關聯模型的範例說明 以一個實際範例來說明如何依據使用者的需求來建立和表達出一個概念實體關聯模型 並且如何來解讀所繪製出來的模型 以學校的學生管理系統來做一闡述範例，並且假設使用者有以下七項的需求產生

第一項需求的解析 『一位學生(學號、姓名、地址、電話、生日、年齡)，可能會有多個電話號碼，以及會有監護人(姓名、關係、地址)，但不是每一位學生都必須有監護人，可視學生年齡是否已經成年，以及可能會有一到多位監護人。』

第一項需求的解析 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 監護人 的監護 1 N 關係 年齡 生日 第一項需求之概念ERD

第二項需求的解析 『學生必須歸屬在某一個科系(科系代號、科系名稱、位置)，也可以同時申請輔系或雙學位，也就是主副修關係。』

第二項需求的解析 第二項需求之概念ERD M N 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 科系 年齡 生日 科系代號 科系名稱 位置 主副修 M N 主副修別 第二項需求之概念ERD

第三項需求的解析 『每一個科系僅會有一個學生代表，參與該科系的科系會議，並且不需要將歷年的學生代表記錄，只要記錄目前的學生代表即可。』

第三項需求的解析 第三項需求之概念ERD 1 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 科系 代表 年齡 生日 科系代號 科系名稱 位置 第三項需求之概念ERD

第四項需求的解析 『每位學生可以自由選修課程(課程代號、必選修別、學分數、科目名稱、先修科目)，但學生的選修結果必須記錄該名學生選修的成績。』

第四項需求的解析 第四項需求之概念ERD

第五項需求的解析 『每一門課程必須限制學生的修課人數，最少必須達到五人，最高不得高於五十人選修該課程。』

第五項需求的解析 第五項需求之概念ERD

第六項需求的解析 『科目之間有可能檔修情形，也就是說，有些科目必須要先修過某些基礎科目之後，方可選修該門科目；而某一個科目也有可能會擋其他多個不同科目的情形，一個科目只會有一個先修科目。』

第六項需求的解析 第六項需求之概念ERD

第七項需求的解析 『每科系可以開出很多不同的課程讓學生來選修；但每一科系所開出的課程，雖然科目名稱有可能在不同科系之間會有相同的情形，但視為不同課程；換句話說，一個課程只會有一個科系開出，不會有多個科系開出完全相同的一門課程。』

第七項需求的解析 第七項需求之概念ERD

第八項需求的解析 所有課程都必須教師(教師代號，姓名)授課，而且每一門課程僅會有一位教師授課；每位教師可以不授課，也可以同時授課多門課程』

第八項需求的解析 第八項需求之概念ERD

完整概念實體關聯模型

http://sourceforge.net/projects/dia-installer/files/dia-win32-installer/0.97.1/dia-setup-0.97.1-2.exe/download

2-8 摘要

相關模型 Data Flow Diagram Entity Relationship Diagram 『資料流程圖』，簡稱DFD 『處理為主』(Process Driven)的模型 Entity Relationship Diagram 『實體關聯圖』，簡稱ERD 『資料為主』 (Data Driven)的模型 大部份使用在資料庫的設計 Unified Modeling Language 『統一塑模語言』，簡稱UML 『物件導向』 (Object Oriented)為主的模型

本章結束 Q&A討論時間