第二章 資料模型 資料庫系統理論與實務 [邏輯思維系列] 第二章 資料模型 資料庫系統理論與實務 [邏輯思維系列]

本章在架構中的位置 MS SQL Server 2005 理論與實作(一) (08) My SQL Server 2005 理論與實作(二)(13) 回復技術(11) 結構化查詢語言 SQL(一)(06) 結構化查詢語言 SQL(二)(07) 與管理(12) 資料庫安全 關聯式代數(05) 並行控制(10) 關聯式模型(03) (正規化) 合併理論(04) 交易處理(09) 資料模型(02) 資料庫系統簡介(01) 邏輯與思維 2 /69

本章內容 2-1塑模(Modeling)與模型(Model) 2-2資料的抽象化 2-3資料模型的重要性 2-4概念實體關聯模型基本認識 2-5概念實體關聯模型及構成要素 2-6概念實體關聯模型的範例說明 3 /69

2-1塑模(Modeling)與模型(Model) 建築公司要賣房子之前，通常會塑造一個依某個比率縮小的模型來提供客戶在『概念上』的參考並介紹；但也有些會依1:1的比例建造一個樣品屋，一切如同真正房屋一般的『實體上』的參考；客戶便可藉由此模型和房屋銷售人員的介紹和溝通，很容易瞭解預售屋的實際情形，來決定是否為自己所喜愛的格局建物，如此可降低在直接購買之後，才發現其格局並非自己所喜歡之格局的風險 塑模(Modeling) 塑造模型的過程 模型(Model) 塑模後的東西 4 /69

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

2-1-1資料流程圖 『處理』(Process) 『資料流』(Data Flow) 『外部實體』 (External Entity) 動詞(Verb) 『資料流』(Data Flow) 名詞，而非動作 『外部實體』 (External Entity) 人 事物 時間 外部系統 『資料儲存體』(Data Storage) 為資料儲存之處 6 /69

代表名詞的『資料流』，學生資訊、註冊證明以及註冊資訊 DFD之範例 – 註冊 代表名詞的 『資料儲存體』 按任意鍵 --- 繼續 --- 代表名詞的『資料流』，學生資訊、註冊證明以及註冊資訊 代表名詞的 『外部實體』 按任意鍵 --- 繼續 --- 按任意鍵 --- 繼續 --- D1 已註冊資料 學生資訊 學生 01 註冊資訊 註冊 註冊證明 代表動作的 註冊『處理』 圖2-1 學生註冊之DFD模型 7 /69

2-1-2實體關聯模型 以『資料』為主要考量方向 基本組成 『基數』(Cardinality)關係 實體(Entity) 關係(Relationship) 『基數』(Cardinality)關係 1：1 ：一對一關係 1：N ：一對多關係 M：1 ：多對一關係 M：N ：多對多關係 8 /69

學生與課程的實體關聯模型 學生 課程 選修 學生與課程 之間的『基數』為M:N 學生與課程 之間的 選修『關係』 學生『實體』 與 課程『實體』 按任意鍵 --- 繼續 --- 按任意鍵 --- 繼續 --- M N 學生 課程 選修 圖2-2 學生選課之資料模型 9 /69

2-1-3統一塑模語言 James Rumbaugh、Ivar Jacobson和Grady Booch等三位博士所創建 已被『美國物件管理協會』 (Object Management Group，簡稱OMG)訂定成依循之標準 目前最新版本為UML2.0，可參考http://www.omg.org官方網站中的相關資料 10 /69

UML的三大類別 結構型圖例(Structure Diagrams)：包括六種圖例 類別圖例(Class Diagram) 物件圖例(Object Diagram) 元件圖例(Component Diagram) 組合結構圖例(Composite Structure Diagram) 套件圖例(Package Diagram) 佈署圖例(Deployment Diagram) 行為型圖例(Behavior Diagrams)：包括三種圖例 互動型圖例(Interaction Diagrams)：包括四種圖例 續下頁 11 /69

UML的三大類別(續) 結構型圖例(Structure Diagrams)：包括六種圖例 行為型圖例(Behavior Diagrams)：包括三種圖例 使用案例圖例(Use Case Diagram) 活動圖例(Activity Diagram) 狀態機圖例(State Machine Diagram) 互動型圖例(Interaction Diagrams)：包括四種圖例 續下頁 12 /69

UML的三大類別(續) 結構型圖例(Structure Diagrams)：包括六種圖例 行為型圖例(Behavior Diagrams)：包括三種圖例 互動型圖例(Interaction Diagrams)：包括四種圖例 序列圖例(Sequence Diagram) 通訊圖例(Communication Diagram) 時間圖例(Timing Diagram) 整體互動圖例(Interaction Overview Diagram) 13 /69

UML2.0語意範圍和彼此相依關係 活動 (Activities) 狀態機 (State Machines) 互動 (Interactions) 動態語意 行動 (Actions) 物件間行為基底 (Inter-Object Behavior Base) 物件內行為基底 (Intra-Object Behavior Base) 結構基礎 (Structural Foundations) 靜態語意 圖2-3 UML的語意概要圖與相依性 14 /69

本章內容 2-1塑模(Modeling)與模型(Model) 2-2資料的抽象化 2-3資料模型的重要性 2-4概念實體關聯模型基本認識 2-5概念實體關聯模型及構成要素 2-6概念實體關聯模型的範例說明 15 /69

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

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

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

本章內容 2-1塑模(Modeling)與模型(Model) 2-2資料的抽象化 2-3資料模型的重要性 2-4概念實體關聯模型基本認識 2-5概念實體關聯模型及構成要素 2-6概念實體關聯模型的範例說明 19 /69

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

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

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

『概念』資料模型與『實體』資料模型 資料模型的表示方式，大致可分為兩種 『概念資料模型』(Conceptual Data Model)或稱為『高階資料模型』(High Level Data Model) 適合一般使用者與系統分析師之間溝通 系統分析師(System Analyst)能從企業客戶身上獲得相關的企業資訊 主要目的在於描述出企業中，每一個實體(Entity)與實體之間的關係 『實體資料模型』(Physical Data Model)或稱為『低階資料模型』(Low Level Data Model) 續下頁 23 /69

『概念』資料模型與『實體』資料模型 資料模型的表示方式，大致可分為兩種 『概念資料模型』(Conceptual Data Model)或稱為『高階資料模型』(High Level Data Model) 『實體資料模型』(Physical Data Model)或稱為『低階資料模型』(Low Level Data Model) 概念資料模型轉為實體資料模型 提供給程式設計人員來實作 除了能展現出每一個實體(Entity)與實體之間的關係(Relationship)之外，更必須要能展現出實體之間的實作方式 24 /69

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

本章內容 2-1塑模(Modeling)與模型(Model) 2-2資料的抽象化 2-3資料模型的重要性 2-4概念實體關聯模型基本認識 2-5概念實體關聯模型及構成要素 2-6概念實體關聯模型的範例說明 26 /69

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

實體 實實在在的物體 在真實世界中，代表著獨立、具體且特定的一個人、事、時、地、物或只是一個概念上的任何事物 例如在某家公司上班的五位員工，每一位員工都算是一個獨立、具體的實體 員工(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巷) 28 /69

圖2-8 實體與屬性 實體 名稱 屬性 實體 型態 員工 員工編號 姓名 年齡 出生日期 訂單編號 地址 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巷 實體集合 實體 圖2-8 實體與屬性 29 /69

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

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

『鍵值屬性』 在一個實體集合中，通常不希望在集合中出現兩個或兩個以上的實體是屬於相同的一個實體，也就是造成了資料的重複 唯一識別該實體的屬性 例如圖2-4中的『員工編號』即為鍵值屬性 鍵值屬性能夠唯一識別該紀錄的屬性，所以 不可有重複值產生 不可有『空值』(Null Value)的情形 32 /69

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

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

地址 區域號碼 縣市 街道 路(街)名 段 巷 弄 號 樓 圖2-9 複合型屬性 35 /69

『儲存型屬性』與『衍生型屬性』 儲存型屬性 衍生型屬性 該屬性的值是必須被儲存下來的 由儲存型屬性，或是其他輸入的資料，例如系統日期/時間，所計算出來或推導出來的值 例如年齡，可藉由現在日期以及出生日期相互計算得之 衍生型屬性的儲存必要性，並沒有一定的規範不儲存於儲存體或資料庫中，可視必要性來決定 36 /69

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

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

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

本章內容 2-1塑模(Modeling)與模型(Model) 2-2資料的抽象化 2-3資料模型的重要性 2-4概念實體關聯模型基本認識 2-5概念實體關聯模型及構成要素 2-6概念實體關聯模型的範例說明 40 /69

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

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

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

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

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

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

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

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

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

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

表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 51 /69

表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} 52 /69

本章內容 2-1塑模(Modeling)與模型(Model) 2-2資料的抽象化 2-3資料模型的重要性 2-4概念實體關聯模型基本認識 2-5概念實體關聯模型及構成要素 2-6概念實體關聯模型的範例說明 53 /69

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

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

圖2-22 第一項需求之概念ERD 1 N 56 /69 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 監護人 的監護 關係 年齡 生日 圖2-22 第一項需求之概念ERD 56 /69

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

圖2-23 第二項需求之概念ERD M N 58 /69 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 科系 年齡 生日 科系代號 科系名稱 位置 主副修 M N 主副修別 圖2-23 第二項需求之概念ERD 58 /69

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

圖2-24 第三項需求之概念ERD 1 60 /69 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 科系 代表 年齡 生日 科系代號 科系名稱 位置 圖2-24 第三項需求之概念ERD 60 /69

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

圖2-25 第四項需求之概念ERD 62 /69 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 選修 成績 M 年齡 生日 N 課程 課程代號 學分數 必選修別 學年學期 科系代號 科目代號 先修科目 科目名稱 圖2-25 第四項需求之概念ERD 62 /69

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

圖2-26 第五項需求之概念ERD 64 /69 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 選修 成績 M 年齡 生日 {5,50} N 課程 課程代號 學分數 必選修別 學年學期 科系代號 科目代號 先修科目 科目名稱 圖2-26 第五項需求之概念ERD 64 /69

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

圖2-27 第六項需求之概念ERD 1 N 66 /69 課程 檔修 課程代號 學分數 先修 後修 必選修別 學年學期 科系代號 科目代號 先修科目 科目名稱 圖2-27 第六項需求之概念ERD 66 /69

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

圖2-28 第七項需求之概念ERD M N 1 68 /69 科系 科系代號 科系名稱 位置 開課 課程 檔修 課程代號 學分數 先修 後修 必選修別 學年學期 科目代號 先修科目 科目名稱 M 圖2-28 第七項需求之概念ERD 68 /69

完整概念實體關聯模型 1 69 /69 電話 學生 學號 姓名 地址 區域號碼 縣市 路名 課程 選修 科系 成績 檔修 課程代號 學分數 代表 M N 監護人 的監護 先修 後修 1 關係 年齡 生日 科系代號 科系名稱 位置 開課 主副修 {5,50} 主副修別 必選修別 學年學期 科目代號 先修科目 科目名稱 69 /69