使用ER模型制作资料模型.ppt

使用ER模型製作資料模型 學習重點 資料庫設計的主要階段 ER模型的觀念 屬性的型態 實體型態與鍵值屬性 關係、關係型態、關係集合 關係型態的限制和屬性 弱實體型態 ER圖中的標記法 (min, max)的ER圖表示法 UML類別圖的表示法 多元關係型態 資料庫設計的主要階段 (1/2) 資料庫設計的主要階段 (2/2) 需求收集與分析(requirements collection and analysis)：資料庫設計者訪問、收集並分析使用者的需求 概念設計(conceptual design)：利用高階概念資料庫模型來為資料庫建立概念綱要(conceptual schema) 邏輯設計(logical design)：此步驟是使用商業DBMS真正的實作資料庫。例如，使用關聯式或物件關聯式資料模型去設計資料庫綱要 實體設計(physical design)：此步驟負責指定資料庫檔案內部儲存結構、索引、存取路徑和檔案組織 資料庫設計程序 兩個主要的動作 資料庫設計 (database design) 這也正是本章所要介紹的方面 本章著重於概念性綱要(conceptual schema)的設計 應用程式設計 (application design) 通常著重於程式和存取資料庫介面的設計 可被視為軟體工程的一部份 COMPANY資料庫範例 (1/2) 公司的需求 這家公司是由多個部門 (DEPARTMENT) 所組成。 每個部門有唯一的名稱、編號，並且由一名部門經理來管理。 必須記錄部門經理開始管理部門的日期。 一個部門可能有好幾個位置。 每個部門都負責控管一些計畫 (PROJECT)。 每個計畫都有一個名稱、編號和唯一的工作地點 COMPANY資料庫範例 (2/2) 公司的需求(續) 必須記錄每位員工(EMPLOYEE)的姓名、社會安全號碼、地址、薪資、性別與生日。 每個員工會被指派到某一個部門，但可能會為好幾個計畫工作。 我們會記錄每位員工，在每個計畫裡的每週工作時數。 我們也會記錄每個員工的直屬主管。 每個員工可能有幾位眷屬(DEPENDENT)。 必須記錄每位眷屬的姓名、性別、生日以及與該員工的關係。 ER綱要圖的範例 ER模型的觀念 ER模型主要是將資料描述成 實體(entity)：真實世界中實際上或概念上存在的物件，如人、車、房子、員工、公司、工作或是大學課程 屬性(attribute)：用來描述實體的特性，如員工的姓名、年紀、地址、薪資 實體的每個屬性都有一個值(value)，此一屬性值就成為儲存在資料庫裡的資料 每個屬性都有一個關聯的數值集合 ，或稱資料型態 (data type)，如整數、字串、… 關係(relationship)：每當實體型態的某個屬性參考到另一個實體型態時，就會有某些關係存在 實體和屬性 圖3.3：Employee實體e1和Company實體c1，及它們的屬性 屬性的型態 (1/4) 簡單屬性 vs. 複合屬性 簡單(simple or atomic)：不可再分割的屬性 例如，Ssn 或 Sex 複合(composite)：可分割成更小、獨立和更基本的屬性 例如，EMPLOYEE的屬性Address可以再細分成Street_address、City、State和Zip 複合屬性的值是簡單屬性值的組合 屬性的型態 (2/4) 單值屬性 vs. 多值屬性 單值(single-valued)：屬性只有單一的值 例如，Age(年齡)是人的單值屬性 多值(multivalued)：屬性可以有一組或多個值 例如，汽車的Colors(顏色)屬性，某人的College_degrees(大學學位)屬性 屬性的型態 (3/4) 內儲屬性 vs. 衍生屬性 例如，Age(年齡)和Birth_date(生日)是人的兩個屬性 然而，Age的值是由今天的日期和人的Birth_date屬性值一起決定的 Birth_date屬性便是內儲屬性(stored attribute) Age屬性則是衍生屬性(derived attribute) 複雜屬性(Complex attribute) 例如，人的實體中有一個address_phone屬性 某人有超過一個以上的住所，而且每個住所都有好幾支電話 其中Phone和Address兩者本身都是複合屬性 屬性的型態 (4/4) 空值(NULL)：實體的某個屬性可能沒有任何適合的值 例如，College_degrees這個屬性只適用於有大學學位的人 空值的發生可能是下列情形之一 不適用(not applicable)： 沒有大學文憑的人，其College_degrees是NULL 未知(unknown)： 存在卻找不到(Exists but is missing) 某個人的Height