延伸式实体关系(EER)模型.ppt

1、延伸式實體關係(EER)模型,第 4 章,資料庫管理,學習重點,延伸式ER (EER) 模型概念 子類別與超類別 特殊化 一般化 特殊化與一般化的限制 特殊化與一般化的插入和刪除規則 特殊化與一般化階層和格狀結構 分類(UNION型態) UML類別圖,資料庫管理,延伸式ER (EER) 模型概念,EER模型(Enhanced-ER或Extended-ER)包含了下列幾種概念： 所有基本ER模型的概念 子類別(subclass)超類別(superclass) 特殊化(specialization)一般化(generalization) 分類(category) 聯集型態(union type)

2、屬性和關係繼承(inheritance),資料庫管理,子類別與超類別 (1/5),一個實體型態可能是由其它實體集合所組成的，例如： EMPLOYEE可以更進一步分組為 SECRETARY、ENGINEER、TECHNICIAN 根據員工的工作性質 MANAGER 根據員工是否為主管 SALARIED_EMPLOYEE、HOURLY_EMPLOYEE 根據員工支領薪水的方式 這些子集合的實體成員，都是屬於EMPLOYEE實體型態的子集合 這些子集合的所有實體都是公司的員工,資料庫管理,子類別與超類別 (2/5),上述EMPLOYEE實體型態與它的子集合之間的關係，被稱之為超類別子類別 (supe

3、rclass/subclass) 關係 每個子集合被稱作是EMPLOYEE的子類別 (subclass) EMPLOYEE則是這些子類別的超類別(superclass) 在圖4.1中，有多個超類別子類別關係 EMPLOYEE/SECRETARY EMPLOYEE/TECHNICIAN EMPLOYEE/MANAGER ,資料庫管理,子類別與超類別 (3/5),資料庫管理,子類別與超類別 (4/5),超類別子類別關係也稱作IS-A 關係，例如 SECRETARY IS-A EMPLOYEE TECHNICIAN IS-A EMPLOYEE 注意： 屬於子類別成員的實體，所代表的真實世界實體，和超

4、類別是一樣的。也就是說，屬於子類別的實體，同時也必定屬於超類別 例如，SECRETARY實體中的 王小妹和EMPLOYEE中的 王小妹是同一個 超類別中的實體不一定會屬於子類別 “貨車司機”在 工作性質的分類中，不屬於任何一個子類別,資料庫管理,子類別與超類別 (5/5),範例： 一個領月薪(全職)的工程師會同時屬於 ENGINEER子類別 SALARIED_EMPLOYEE子類別 一個領月薪(全職)的工程師主管會同時屬於 ENGINEER子類別 SALARIED_EMPLOYEE子類別 MANAGER子類別 屬性和關係的繼承 子類別的實體會繼承(inherit)超類別中相同實體之全部屬性，及

5、超類別所參與的關係 子類別可能具有自己的屬性和關係,資料庫管理,特殊化 (1/4),特殊化(Specification)：定義超類別實體型態中一組子類別的程序 每組子類別是根據超類別實體中不同的特性定義而成。在圖4.1中 SECRETARY, ENGINEER, TECHNICIAN 是根據其超類別EMPLOYEE實體的工作性質特殊化而來 SALARIED_EMPLOYEE, HOURLY_EMPLOYEE是依照付薪方式將EMPLOYEE特殊化而來 同一個超類別可能會有數種特殊化方式,資料庫管理,特殊化 (2/4),表示法與討論： 連結子類別和超類別的實線就代表特殊化 只套用在特定子類別實體上

6、的屬性被稱作特殊屬性 (specific attribute)或區域屬性(local attribute) 如圖4.1中，SECRETARY的TypingSpeed 子類別也可以參與特殊的關係型態 如圖4.1中， HOURLY_EMPLOYEE會參與BELONGS_TO關係 特殊化可能只包含一個子類別 如圖4.1中，MANAGER子類別 此情況下，不採用圓形符號來表示,資料庫管理,特殊化 (3/4),資料模型包含超類別子類別的兩個理由 屬性：某些特別的屬性是應用到實體型態中部份但並非全部的實體 在圖4.1中，SECRETARY類別才有Typing_speed這個屬性 在圖4.1中，ENGINE

7、ER類別則有Eng_type這個屬性 在圖4.1中， SECRETARY和ENGINEER類別的其他屬性則繼承自EMPLOYEE類別 關係：某些關係型態只存在於某個子類別成員的實體 在圖4.1中，只有HOURLY_EMPLOYEE可加入工會(trade union)，所以透過 BELONGS_TO關係去產生關聯,資料庫管理,特殊化 (4/4),總而言之，特殊化的過程會進行下列動作 定義實體型態的一組子類別 在每個子類別中增加額外的特殊化屬性 在不同子類別之間，或是與其它實體型態或子類別之間，建立額外的特殊化關係型態,資料庫管理,一般化 (1/2),一般化(Generalization)：特殊化

8、的反向程序 將數個具有共同功能的類別一般化成為一個超類別，而原始的類別則變成它的子類別 以圖4.3為例： 圖4.3(a)中有CAR和TRUCK兩個實體型態 這兩個實體型態可被一般化成為VEHICLE實體型態，如圖4.3(b)所示。 此時CAR和TRUCK兩者都成為超類別VEHICLE的子類別 我們可以將 CAR, TRUCK 視為VEHICLE的特殊化結果 從另一方面來看，也可以將VEHICLE視為將CAR與TRUCK一般化之後的結果,資料庫管理,一般化 (2/2),資料庫管理,特殊化與一般化的限制 (1/6),假如可以藉由限定超類別的某些屬性值，即可決定出子類別的成員實體，這些子類別就稱為述

9、詞定義（predicate-defined）子類別，或稱條件定義（condition-defined）子類別 所謂的條件，是決定子類別成員的限制 述詞定義子類別的表達方式是在子類別與其超類別圓形連結的線段旁對應的述詞 如圖4.4中，Job_type=Secretary這個述詞用來設定SECRETARY子類別的成員條件,資料庫管理,特殊化與一般化的限制 (2/6),資料庫管理,特殊化與一般化的限制 (3/6),假如在特殊化的過程中，所有子類別與超類別屬性有相同的成員條件，則此特殊化稱為屬性定義特殊化 (attribute defined-specialization) 此屬性被稱作特殊化的定義屬

10、性（defining attribute） 範例：JobType是從EMPLOYEE形成 SECRETARY, TECHNICIAN, ENGINEER 這個特殊化過程的定義屬性 假如沒有這種定義成員的條件，此時這子類別就稱為使用者定義 (user-defined) 的子類別 這種子類別的成員，是由資料庫使用者執行新增動作所決定 每一個子類別中的成員是由使用者個別加入到子類別中，而不是依特定條件組成的,資料庫管理,特殊化與一般化的限制 (4/6),特殊化另外有二種限制： 分離性限制 (disjointness constraint) 完全性限制 (completeness constraint

11、) 分離性限制 (disjointness constraint)： 分離的(disjoint) 指定特殊化的子類別必須是分離的 一個實體最多只能屬於一個特殊化的子類別 在EER圖中用 d 來表示 重疊的(overlapping) 子類別不是分離的，它們的實體可能重疊 (overlap) 相同實體可能屬於多個子類別 在EER圖中用o 來表示,資料庫管理,特殊化與一般化的限制 (5/6),完全性限制 (completeness constraint)： 全部(total) 全部特殊化是限定超類別中的每個實體都必須屬於特殊化的子類別 在EER圖中是以雙實線來表示 部份(partial) 部份特殊化

12、則是允許實體可以不屬於任何一個子類別 在EER圖中是以單實線來表示,資料庫管理,特殊化與一般化的限制 (6/6),分離性限制與完全性限制是互相獨立的 因此可得到以下4種可能的特殊化限制： 分離且全部特殊化 (disjoint, total) 分離且部份特殊化 (disjoint, partial) 重疊且全部特殊化 (overlapping, total) 重疊且部份特殊化 (overlapping, partial) 注意：一般化的超類別通常是全部的，因為這個超類別是由子類別導出的,資料庫管理,分離且部份特殊化範例,資料庫管理,重疊且全部特殊化範例,資料庫管理,特殊化與一般化的插入和刪除規則

13、,一些適用於特殊化與一般化的插入和刪除規則 假如刪除超類別中的某個實體，則自動從所有子類別中刪除同一實體 假如在超類別中插入一個實體，則在所有述詞定義(或屬性定義)子類別中，也會自動強制加入符定定義述詞的實體 如果在全部特殊化的超類別中加入一個實體，則該實體也會被強制加入到至少一個特殊化的子類別中,資料庫管理,特殊化與一般化階層和格狀結構 (1/3),子類別之下可能有自己的子類別，而形成一個特殊化的階層 (hierarchy ) 或特殊化的格狀結構 (lattice)，如圖4.6 階層：限制每個子類別只能有一個超類別 稱作單一繼承 格狀結構：一個子類別可以是多個超類別的子類別 稱作多重繼承 無

14、論是在階層或格狀結構中，子類別不只是會從它的直接超類別繼承屬性，而是所有的上層超類別都繼承,資料庫管理,特殊化與一般化階層和格狀結構 (2/3),資料庫管理,特殊化與一般化階層和格狀結構 (3/3),共用子類別 (shared subclass)：一個具有多個超類別的子類別，則稱之。 如圖4.6中的ENGINEERING_MANAGER 有特殊化階層和格狀結構，同樣也有一般化階層和一般化格狀結構 特殊化程序：首先從某個實體型態開始，一直往下定義它的子類別 由上而下概念精化的過程 一般化程序：首先從多個實體型態開始，找出它們的共同特性 由下而上概念合成的過程 在實務上也可以將這兩種程序合併使用,

15、資料庫管理,特殊化與一般化格狀結構範例 (1/4),資料庫管理,特殊化與一般化格狀結構範例 (2/4),圖4.7中，UNIVERSITY資料庫部份需求如下： 資料庫儲存三種人的資料：員工(EMPLOYEE)、校友(ALUMNUS)和學生(STUDENT) 每個人可隸屬其中幾種類型 每個人都有記錄姓名、SSN、性別、地址和生日 員工(employee)：分成教員(faculty)、職員(staff)和學生助理(student assistant)三類 每個員工都有薪水(Salary) 每個員工只能隸屬於其中一類 校友(alumnus)：會記錄他/她所取得的一或多個學位(Degrees)，它包括

16、學位名稱(Degree)、哪一年取得(Year)，以及主修科系(Major),資料庫管理,特殊化與一般化格狀結構範例 (3/4),教員(faculty)：記錄他/她的職等(rank) 職員(staff)；記錄他/她的職位(position) 學生助理(student_assistant)：又分成研究助理(research_assistant)及教學助理(teaching_assistant) 記錄每位學生助理的工作時間比例(percent_time) 記錄研究助理所進行的研究計劃(project) 記錄教學助理所負責協助的課程(course) 學生(student)：又分成大學部(underg

17、raduate_student)及研究生(graduate_student) 每個學生都有一個主修科系(Major_dept) 記錄大學部學生的年級(class) 記錄研究生攻讀的學位(degree_program),資料庫管理,特殊化與一般化格狀結構範例 (4/4),圖4.7 UNIVERSITY資料庫需求的進一步修訂補充 PERSON可特殊化成EMPLOYEE, ALUMNUS, STUDENT這三個子類別 校友(alumnus)可能是員工(employee)，也可能是從大學部畢業正在攻讀碩士的研究生 所以選擇使用重疊性限制(符號：o) STUDENT子類別是GRADUDATE_STUDE

18、NT, UNDERGRADUATE_STUDENT特殊化的超類別 EMPLOYEE是STUDENT_ASSISTANT, FACULTY, STAFF特殊化的超類別 STUDENT_ASSISTANT也是STUDENT的子類別 STUDENT_ASSISTANTD是RESEARCH_ASSISTANT, TEACHING_ASSISTANT的超類別,資料庫管理,分類(UNION型態)：(1/6),前面內容的子類別類別關係都只有單一超類別 共用子類別雖然是具有多個分開的超類別子類別關係的子類別，但它的每個關係都只有一個超類別 (多重繼承) 如圖4.7中，共用子類別ENGINEERING_MANA

19、GER雖然有三個子類別超類別關係，但這三個關係個別都只有一個超類別 聯集實體(union type)或分類 (category)： 在某些情況是需要將單一的超類別子類別關係建構成多個超類別，這些超類別分別代表不同的實體型態 在圖4.8中，OWNER即是UNION型態,資料庫管理,分類(UNION型態)：(2/6),資料庫管理,分類(UNION型態)：(3/6),在圖4.8中，記錄汽車登記的資料庫中，車子擁有者可以是人(person)、銀行(bank, 有車子抵押權)或公司(company) 此時，聯集(union)型態 OWNER是 PERSON, BANK和COMPANY三個超類別的聯集的子

20、集合 聯集型態OWNER的成員必須存在於至少一個它的超類別中 聯集型態與共用子類別的不同 共用子類別的成員必須存在於所有超類別中 共用子類別是其超類別交集的子集合 聯集型態可能有兩個或更多個超類別，而這些超類別可能代表不同的實體型態,資料庫管理,分類(UNION型態)：(4/6),圖4.8與圖4.6的比較 在圖4.8，聯集型態OWNER OWNER的實體必須至少存在於一個超類別，而且只能一個。也就是說，OWNER可能是PERSON, BANK或COMPANY的一份子 依它隸屬的超類別，決定它要繼承的屬性 在圖4.6，共用子類別ENGINEERING_MANAGER 它是屬於ENGINEER、M

21、ANAGER和SALARIED_EMPLOYEE三個超類別的子類別 一個屬於ENGINEERING_MANAGER的實體，必須同時存在於ENGINEER、MANAGER和SALARIED_EMPLOYEE三者之中 繼承所有超類別的全部屬性,資料庫管理,分類(UNION型態)：(5/6),圖4.8與圖4.3(b)的差異比較 在圖4.8 REGISTERED_VEHICLE分類不一定包括全部的CAR和TRUCK 因為，可能有部份車子(CAR)或卡車(TRUCK)並沒有登記(register) 在圖4.3(b) 每一個CAR和TRUCK都是VEHICLE 分類聯集型態的討論 分類可以是全部(tota

22、l)或部份(partial) 全部的分類：包含所有超類別中所有實體的聯集，以雙線連接分類與圓圈 部份的分類：則是聯集某一部份的子集合，以單線表示 分類的超類別可能會有相同或不同鍵值屬性 OWNER分類的超類別是不同鍵值 REGISTERED_VEHICLE分類的超類別是相同鍵值,資料庫管理,分類(UNION型態)：(6/6),圖4.3(b)：將CAR和TRUCK一般化產生超類別VEHICLE,資料庫管理,University的EER綱要範例 (1/5),資料庫管理,University的EER綱要範例 (2/5),每個人(PERSON)的個人資料：姓名(name)、社會安全號碼(Ssn)、地址

23、(Address)、性別(Sex)和生日(Bdate) PERSON實體型態有兩個子類別 教職員(FACULTY)：職等(Rank)、辦公室(Foffice)、辦公室電話(Fphone)和薪資(Salary) 學生(STUDENT)：年級(Class) 大一=1，大二=2，大三=3，大四=4，研究生=5 學生必須記錄他/她的 主修系所(MAJOR) 輔修系所(MINOR) 目前所選修的課程(REGISTERED) 成績(TRANSCRIPT)：包含學生的分數(Grade) 系所(DEPARTMENT)：名稱(Dname)、電話(Dphone)、辦公室號碼(Office),資料庫管理,Unive

24、rsity的EER綱要範例 (3/5),教職員vs.所屬系所：以BELONGS建立其關聯性 一個教職員可同時屬於數個系所，關係為M：N 研究生(GRAD_STUDENT)：學位(Degrees，多值屬性) Degrees為複合屬性，包含College, Degree, Year三個屬性 研究生vs.指導教授：以ADVISOR建立其關聯性 研究生vs.論文委員：以COMMITTEE建立其關聯性 學院(COLLEGE)：學院名稱(Cname)、辦公室號碼(Coffice)和院長姓名(Dean) 系所vs.系主任：以CHAIRS建立其關聯性 系所vs.學院：以CD建立其關聯性 課程(COURSE)：

25、課程代號(C#)、課程名稱(Cname)和課程簡介(Cdesc),資料庫管理,University的EER綱要範例 (4/5),課程vs.系所：以 DC 建立其關聯性 一個系所可以開多門課程 課程班級(SECTION)：班別編號(Sec#)、開課的學期(Qtr)和開課的年份(Year) 目前課程班級(CURRENT_SECTION)：代表這學期所開的班，因此是SECTION的子類別 定義述詞為Qtr=Current_qtr and Year=Current_year 課程vs.課程班級：以 CS 建立其關聯性 一門課可開授多個課程班級 授課教師(INSTRUCTOR_RESEARCHER)：是

26、教職員(FACULTY)和研究生(GRAD_STUDENT)聯集的子集合 課程班級vs.授課教師：以TEACH建立其關聯性,資料庫管理,University的EER綱要範例 (5/5),補助計劃(GRANT)：名稱(Title)、補助編號(No)、提供單位(Agency)和開始日期(St_date) 補助計劃vs.教職員：以 PI 建立其關聯性 教職員可能擔任多個補助計劃的主持人 補助計劃vs.授課教師：以SUPPORT建立其關聯性 記錄所有參與的人員 必須記錄補助開始日期(Start)、結束日期(End)和人員執行計劃的時間(Time) 每個計劃可能有多個參與人員 每個人員可能參與多個計劃,

27、資料庫管理,UML類別圖 (1/2),特殊化一般化與繼承的UML表示法 以水平線與垂直線連接子類別，並用一個三角形以垂直線連到其超類別 空白三角形：代表特殊化/一般化的分離性限制 填滿三角性：代表特殊化/一般化的重疊性限制 基底類別(base class)：指最上面的超類別 如圖4.10中的PERSON類別 末端類別(left class)：指末端的節點類別 允許單一或多重繼承關係,資料庫管理,UML類別圖 (2/2),資料庫管理,不同表示法的符號比較,資料庫管理,小型機場的EER綱要範例 (1/4),資料庫管理,Each AIRPLANE has attribute Reg#, is of

28、a particular plane type OF_TYPE, and is stored in a particular hangar STORE_IN. Each PLANE_TYPE has attributes: Model, Capacity, Weight. Each HANGER has attributes: Number, Capacity, Location. The database also keeps track of the OWNERs of each plane OWNS and the EMPLOYEEs who have maintained the plane MAINTAIN. Each relationship instance in OWNS relates an AIRPLANE to an OWNER and includes the purchase date Pdate. Each relationship instance in MAINTAIN relates an EMPLOYEE to a service record SERVICE.,小型機場的EER綱要範例 (2/4),資料庫管理,Each plane undergoes servic