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

上传人:本田雅阁 文档编号:2635787 上传时间:2019-04-25 格式:PPT 页数:71 大小:2.02MB
返回 下载 相关 举报
使用ER模型制作资料模型.ppt_第1页
第1页 / 共71页
使用ER模型制作资料模型.ppt_第2页
第2页 / 共71页
使用ER模型制作资料模型.ppt_第3页
第3页 / 共71页
使用ER模型制作资料模型.ppt_第4页
第4页 / 共71页
使用ER模型制作资料模型.ppt_第5页
第5页 / 共71页
点击查看更多>>
资源描述

《使用ER模型制作资料模型.ppt》由会员分享,可在线阅读,更多相关《使用ER模型制作资料模型.ppt(71页珍藏版)》请在三一文库上搜索。

1、使用ER模型製作資料模型,第 3 章,資料庫管理,2,學習重點,資料庫設計的主要階段 ER模型的觀念 屬性的型態 實體型態與鍵值屬性 關係、關係型態、關係集合 關係型態的限制和屬性 弱實體型態 ER圖中的標記法 (min, max)的ER圖表示法 UML類別圖的表示法 多元關係型態,資料庫管理,3,資料庫設計的主要階段 (1/2),資料庫管理,4,資料庫設計的主要階段 (2/2),需求收集與分析(requirements collection and analysis):資料庫設計者訪問、收集並分析使用者的需求 概念設計(conceptual design):利用高階概念資料庫模型來為資料庫建

2、立概念綱要(conceptual schema) 邏輯設計(logical design):此步驟是使用商業DBMS真正的實作資料庫。例如,使用關聯式或物件關聯式資料模型去設計資料庫綱要 實體設計(physical design):此步驟負責指定資料庫檔案內部儲存結構、索引、存取路徑和檔案組織,資料庫管理,5,資料庫設計程序,兩個主要的動作 資料庫設計 (database design) 這也正是本章所要介紹的方面 本章著重於概念性綱要(conceptual schema)的設計 應用程式設計 (application design) 通常著重於程式和存取資料庫介面的設計 可被視為軟體工程的一

3、部份,資料庫管理,6,COMPANY資料庫範例 (1/2),公司的需求 這家公司是由多個部門 (DEPARTMENT) 所組成。 每個部門有唯一的名稱、編號,並且由一名部門經理來管理。 必須記錄部門經理開始管理部門的日期。 一個部門可能有好幾個位置。 每個部門都負責控管一些計畫 (PROJECT)。 每個計畫都有一個名稱、編號和唯一的工作地點,資料庫管理,7,COMPANY資料庫範例 (2/2),公司的需求(續) 必須記錄每位員工(EMPLOYEE)的姓名、社會安全號碼、地址、薪資、性別與生日。 每個員工會被指派到某一個部門,但可能會為好幾個計畫工作。 我們會記錄每位員工,在每個計畫裡的每週工

4、作時數。 我們也會記錄每個員工的直屬主管。 每個員工可能有幾位眷屬(DEPENDENT)。 必須記錄每位眷屬的姓名、性別、生日以及與該員工的關係。,資料庫管理,8,ER綱要圖的範例,資料庫管理,9,ER模型的觀念,ER模型主要是將資料描述成 實體(entity):真實世界中實際上或概念上存在的物件,如人、車、房子、員工、公司、工作或是大學課程 屬性(attribute):用來描述實體的特性,如員工的姓名、年紀、地址、薪資 實體的每個屬性都有一個值(value),此一屬性值就成為儲存在資料庫裡的資料 每個屬性都有一個關聯的數值集合 ,或稱資料型態 (data type),如整數、字串、 關係(r

5、elationship):每當實體型態的某個屬性參考到另一個實體型態時,就會有某些關係存在,資料庫管理,10,實體和屬性,圖3.3:Employee實體e1和Company實體c1,及它們的屬性,資料庫管理,11,簡單屬性 vs. 複合屬性 簡單(simple or atomic):不可再分割的屬性 例如,Ssn 或 Sex 複合(composite):可分割成更小、獨立和更基本的屬性 例如,EMPLOYEE的屬性Address可以再細分成Street_address、City、State和Zip 複合屬性的值是簡單屬性值的組合,屬性的型態 (1/4),資料庫管理,12,單值屬性 vs. 多值

6、屬性 單值(single-valued):屬性只有單一的值 例如,Age(年齡)是人的單值屬性 多值(multivalued):屬性可以有一組或多個值 例如,汽車的Colors(顏色)屬性,某人的College_degrees(大學學位)屬性,屬性的型態 (2/4),資料庫管理,13,屬性的型態 (3/4),內儲屬性 vs. 衍生屬性 例如,Age(年齡)和Birth_date(生日)是人的兩個屬性 然而,Age的值是由今天的日期和人的Birth_date屬性值一起決定的 Birth_date屬性便是內儲屬性(stored attribute) Age屬性則是衍生屬性(derived attr

7、ibute) 複雜屬性(Complex attribute) 例如,人的實體中有一個address_phone屬性 某人有超過一個以上的住所,而且每個住所都有好幾支電話 其中Phone和Address兩者本身都是複合屬性,資料庫管理,14,屬性的型態 (4/4),空值(NULL):實體的某個屬性可能沒有任何適合的值 例如,College_degrees這個屬性只適用於有大學學位的人 空值的發生可能是下列情形之一 不適用(not applicable): 沒有大學文憑的人,其College_degrees是NULL 未知(unknown): 存在卻找不到(Exists but is missin

8、g) 某個人的Height(身高)屬性為NULL 不知道(Not known) 某個人的Home_phone(家裡電話)屬性為NULL,資料庫管理,15,實體型態(entity type):定義相同屬性的實體集合。例如EMPLOYEE實體型態或PROJECT實體型態 實體集合(entity set):在資料庫中,任何時間點某個特定的實體型態的所有實體的集合,實體型態與鍵值屬性 (1/4),資料庫管理,16,實體型態與鍵值屬性 (2/4),鍵值屬性 (key attribute):是實體型態的某個或多個屬性,其值與集合中其他個別的實體都不相同。 例如,EMPLOYEE的Ssn 它的值可用來確認每

9、個實體的唯一性 鍵值屬性可能是複合的。 例如,Registration是CAR實體型態的鍵值,它是由 Number和State所組成的複合鍵值 弱實體型態(weak entity):實體型態沒有任何的鍵值,則稱之。,資料庫管理,17,實體型態與鍵值屬性 (3/4),一個實體型態可能會有一個以上的鍵值。 例如,CAR實體型態可能會有兩個鍵值:Vehicle_id 與Registration屬性,資料庫管理,18,實體型態與鍵值屬性 (4/4),定義域 (domain):指派給實體型態中簡單屬性的資料值集合(value set) 資料值集合一般是以資料型態(data type)來定義,例如整數(i

10、nteger)、字串(string)、布林值(boolean)、浮點數(float)、列舉(enumerated)型態、日期/時間等。,資料庫管理,19,COMPANY資料庫的初步設計 (1/2),根據前面的需求,可先找出四種實體型態 DEPARTMENT: 屬性:Name、Number、Locations、Manager 和Manager_start_date 其中Location是多值屬性 因為Name與Number都是唯一的,所以我們可以指定Name與Number其中之一為鍵值屬性 PROJECT: 屬性:Name、Number、Location 和 Controlling_depart

11、ment Name與Number其中之一可為鍵值屬性,資料庫管理,20,COMPANY資料庫的初步設計 (2/2),EMPLOYEE: 屬性:Name、Ssn、Sex、Address、Salary、Birth_date、Department 和 Supervisor 其中Name與Address可能為複合屬性(需與使用者再次溝通確認)。例如,Name 可能包含First_name、Middle_initial、Last_name DEPENDENT: 屬性:Employee、Dependent_name、Sex、Birth_date 和 Relationship(與員工之間的關係),資料庫管理

12、,21,實體型態的初步設計範例,資料庫管理,22,在二個或多個分開的實體間經常存在具有某種特定意義的關係。 EMPLOYEE Franklin Wong負責管理Research DEPARTMENT EMPLOYEE John Smith工作於Productx計劃 相同型態的關係組成一個關係型態(relationship type) WORKS_ON關係型態是EMPLOYEE實體與PROJECT實體之間的關連 MANAGES關係型態是EMPLOYEE實體與DEPARTMENT實體之間的關連,關係與關係型態 (1/3),資料庫管理,23,關係與關係型態 (2/3),事實上,當實體的某個屬性參考到

13、另一個實體型態時,就會有某些關係存在 DEPARTMENT的Manager屬性參考到管理此部門的某位員工 PROJECT的Controlling_department屬性參考到負責管理此計劃的部門 EMPLOYEE的Supervisor屬性參考到另一位員工(管理此員工的人) EMPLOYEE的Department屬性參考到員工所工作的部門,資料庫管理,24,關係型態的向度 (degree) 是指參與實體型態的個數。 例如,MANAGES和WORKS_ON都是二元 (binary)關係型態 在相同的一組參與的實體型態中,可以存在一個以上的關係型態 例如,MANAGES與WORKS_FOR是EMP

14、LOYEE與DEPARTMENT之間的兩個不同的關係,它們的意義不同,關係實例也不同,關係與關係型態 (3/3),資料庫管理,25,WORKS_FOR關係型態的關係實例,資料庫管理,26,WORKS_ON關係型態的關係實例,資料庫管理,27,關係型態與關係集合,關係型態(relationship type) 是一個關係的綱要描述(schema description) 確認關係名稱和參與的實體型態 確認某些關係限制 關係集合(relationship set) 資料庫中關係實例(relationship instance)的目前集合 關係型態的目前狀態 在ER圖中,表示關係型態的方式如下 菱形

15、方塊用來表示關係型態 以直線連接參與的實體型態,資料庫管理,28,依關係修訂COMPANY資料庫,在所有實體型態中,共存在六個二元關係(binary relationship) WORKS_FOR(在EMPLOYEE和DEPARTMENT間) MANAGES(在EMPLOYEE和DEPARTMENT間) CONTROLS(在DEPARTMENT和PROJECT間) WORKS_ON(在EMPLOYEE和PROJECT間) SUPERVISION(在EMPLOYEE和EMPLOYEE間) DEPENDENTS_OF(在EMPLOYEE和DEPENDENT間),資料庫管理,29,關係型態的討論,在

16、精製過程中,某些原始實體型態中的屬性會成為關係 (參考圖3.8) DEPARTMENT的Manager MANAGES EMPLOYEE的Works_on WORKS_ON EMPLOYEE的Department WORKS_FOR etc. 同一組參與關係的實體間,可能存在一個以上的關係型態,例如: MANAGES和WORKS_FOR是實體EMPLOYEE和DEPARTMENT間兩個不同的關係型態,資料庫管理,30,角色名稱與遞迴關係,每個參與關係型態的實體型態,在關係中會扮演特定的角色(role) 例如,在關係WORKS_FOR中,EMPLOYEE扮演員工或工作者的角色,而DEPARTME

17、NT則扮演部門或雇主的角色 同樣的實體可能會以不同的角色參與關係型態 例如,EMPLOYEE在SUPERVISION關係中參與了兩次:一次是主管的角色,一次是下屬的角色 圖3.11中,標記1的線段代表主管的角色,而標記2的線則代表下屬的角色。,資料庫管理,31,遞迴關係的範例,資料庫管理,32,基數比 (cardinality ratio):代表一個實體所能參與的關係實例的最大個數。 二元關係型態基數比的可能值: 一對一 (1:1):圖3-12 一對多 (1:N) 或多對一 (N:1):圖3-9 多對多 (M:N) :圖3-13,關係型態的限制 (1/3),資料庫管理,33,一對一的二元關係,

18、資料庫管理,34,多對一的二元關係,資料庫管理,35,多對多的二元關係,資料庫管理,36,關係型態的限制 (2/3),參與限制(participation constraint):指定實體的存在是否依靠經由關係型態與另一實體產生關聯來決定 也稱為最小基數限制(minimum cardinality constraint) 零 (可選擇的,非存在相依性) 一或多 (強制的,存在相依性),資料庫管理,37,關係型態的限制 (3/3),參與限制有兩種型態 全部參與(total participation) 實體型態中的每個實體至少要參與關係型態中的一個關係,如圖3-9 也稱為存在相依性(existe

19、nce dependency) 在ER圖中,以雙線表示之 部份參與(partial participation) 並非實體型態中的所有實體都有參與關係型態中的一個關係,如圖3-12 在ER圖中,以單線表示之 基數比和參與限制通常合稱為關係型態的結構限制(structural constraint),資料庫管理,38,關係型態也可以擁有屬性,例如 WORKS_ON關係的Hours屬性 記錄某位EMPLOYEE在某個PROJECT上的工作時數 MANAGES關係的Start_date屬性 表示某個員工開始管理某個部門的日期 關係型態的屬性 在1:1關係型態中的屬性,可以移轉到其中任何一個參與的實體

20、型態裡 在1:N關係型態中的屬性,只能移轉到N這一邊的實體型態裡 在M:N關係型態中的屬性,不能被移轉到實體型態裡,關係型態的屬性,資料庫管理,39,弱實體型態(weak entity type):本身沒有鍵值屬性的實體型態 強實體型態(strong entity type):有鍵值屬性的正常實體型態 弱實體型態必須參與某些實體型態才能存在 這個被依賴的實體型態稱為識別 (identifying) 或擁有者 (owner) 實體型態 弱實體的識別是依據以下的組合: 弱實體型態的某個部份鍵 (partial key) 與識別實體型態相關聯的某個實體,弱實體型態 (1/3),資料庫管理,40,弱實

21、體型態 (2/3),弱實體型態其識別關係一定會存在有全部參與限制 不過,並不是所有的存在相依性都會產生弱實體型態 例如,DRIVER_LICENSE(駕照)實體,它有自己的鍵值(License_number),且不是弱實體型態,但除非它與某個PERSON實體相關,否則就無法存在 DEPENDENT(眷屬)是弱實體 兩個不同員工的眷屬可能在Name、Birth_date、Sex和Relationship中有相同的值,但他們仍舊是不同的實體 EMPLOYEE是它的識別實體型態 識別關係型態為DEPENDENT_OF DEPENDENT的部份鍵是Name,資料庫管理,41,弱實體型態 (3/3),在

22、ER圖中的表示法 弱實體型態:雙線矩形 識別關係:雙線菱形 部份鍵屬性:虛線(dashed line)或點線(dotted line),資料庫管理,42,進一步修訂COMPANY資料庫 (1/4),MANAGES 一個在EMPLOYEE和DEPARTMENT之間的1:1關係型態 EMPLOYEE的參與為部份參與 DEPARTMENT的參與為全部參與(假設每個部門一定要有一位經理) 這個關係型態中有Start_date屬性 WORKS_FOR 一個在DEPARTMENT和EMPLOYEE之間的1:N關係型態 兩者都是全部參與,資料庫管理,43,進一步修訂COMPANY資料庫 (2/4),CONT

23、ROLS 一個在DEPARTMENT和PROJECT之間的1:N關係型態 PROJECT的參與為全部參與 DEPARTMENT的參與為部份參與(因為某些部門可能沒有負責管理任何專案) SUPERVISION 一個在EMPLOYEE(主管角色)和EMPLOYEE (下屬角色)之間的1:N關係型態 兩者都是部份參與(因為不是每個員工都是主管,而且不是每個員工都有主管),資料庫管理,44,進一步修訂COMPANY資料庫 (3/4),WORKS_ON 一個在EMPLOYEE和PROJECT之間的M:N關係型態 兩者都是全部參與(因為一個員工可以參與多個計劃,且好幾個員工可以同時參與相同的計劃) 這個關

24、係型態中有Hours屬性 DEPENDENTS_OF 一個在EMPLOYEE和DEPENDENT之間的1:N關係型態 它是弱實體型態DEPENDENT的識別關係 EMPLOYEE的參與為部份參與 DEPENDENT則是全部參與,資料庫管理,45,進一步修訂COMPANY資料庫 (4/4),指定完上述6個關係型態後,可將圖3.8的實體型態中部份屬性移除 從DEPARTMENT中 移除Manager和Manager_start_date 從PROJECT中 移除 Controlling_department 從EMPLOYEE中 移除 Department、Supervisor和Works_on

25、從DEPENDENT中 移除 Employee,資料庫管理,46,ER圖中的標記法,資料庫管理,47,(min, max)表示法:用一對整數值(min, max)來代表,某個關係型態R對實體型態E的每個參與關係 在E中的每個實體e參與R中最少min而且最多max個關係實例 min=0代表部份參與,而min0代表全部參與 預設值 (沒有限制):min=0, max=n 0 min max 且 max 1,另一種ER圖的表示法 (min, max),資料庫管理,48,假設每個部門剛好有一位經理,而且每個員工最多只能管理(MANAGES)一個部門 指定EMPLOYEE參與MANAGES關係的限制為(

26、0, 1) 指定DEPARTMENT參與MANAGES關係的限制為(1, 1) 每位員工剛好隸屬於(WORKS_FOR)一個部門,而每個部門的員工數可以是任何值 指定EMPLOYEE參與WORKS_FOR關係的限制為(1, 1) 指定DEPARTMENT參與WORKS_FOR關係的限制為 (0, n),(min, max)表示法的範例,資料庫管理,49,(min, max)表示法的範例圖解,資料庫管理,50,(min, max)表示法之COMPANY資料庫的ER圖,資料庫管理,51,UML類別圖的符號表示法 (1/3),UML類別圖 在ER中的實體型態對應到UML是類別(class) 在ER中

27、的實體在UML則是對應到物件(object) 類別(class)是以方形來表示,包含三個部分: 最上方是類別名稱 (class name) 中間是描述類別中個別物件的屬性 (attribute) 最下方則是這些物件的運算動作 (operation),資料庫管理,52,類別中的關係稱作關聯(association),而對映的關係則稱作連結(link) 關聯是以線段來連接參與的類別 關聯屬性被稱作連結屬性(link attribute),它是以一個方框來表示,並以虛線連接至關聯的線段上 關係限制是以最小值最大值(minmax) 來表示 星號(*)表示沒有最大值的限制,UML類別圖的符號表示法 (2

28、/3),資料庫管理,53,UML類別圖的符號表示法 (3/3),UML中有二種關係:關聯(association)與聚合(aggregation) 在ER模式中這二種都視為關係 聚合是代表整體物件與其部分元件之間的關係 用菱形圖形來表示 如圖3.16中,部門(DEPARTMENT)所在地點 如圖3.16中,專案(PROJECT)的地點 弱實體:使用限制關聯(qualified association)或限制聚合(qualified aggregation)的組件來表示 用一個方框附在擁有者類別的下方 如圖3.16中DEPENDENT類別與EMPLOYEE類別,資料庫管理,54,以UML類別圖的

29、表示法表示COMPANY,資料庫管理,55,更高向度的關係,向度等於2的關係型態稱為二元 (binary) 向度等於3的關係型態稱為三元 (ternary) 向度等於n的關係型態稱為n元 (n-ary) 通常n元關係並不等於 n 個二元關係 三個二元關係可能代表著和一個三元關係不同的資訊 通常一個三元關係所代表的資訊,比三個二元關係要來得多,資料庫管理,56,n 元關係的討論,三元關係型態的範例: 圖3.17(a):一個三元關係 SUPPLY 圖3.17(b):三個二元關係,CAN_SUPPLY、 USES和SUPPLIES CAN_SUPPLY、 USES和SUPPLIES這三個關係實例(s

30、, p)、(j, p)和(s, j)已經存在,並不表示三元關係SUPPLY中的實例(s, j, p)一定存在 有些資料庫設計工具只容許二元關係的ER模型,此時像SUPPLY這類的三元關係,就必須表示成弱實體型態,如圖3.17(c) 弱實體型態可能會具有三元(或是 n 元)識別關係型態,如圖3.19所示 此時弱實體便可擁有多個擁有者實體型態,資料庫管理,57,三元關係型態的範例,資料庫管理,58,弱實體型態的三元關係範例,資料庫管理,59,飛航預約系統的ER圖,資料庫管理,60,AIRPORT The database represents each AIRPORT, keeping its u

31、nique AirportCode, the AIRPORT Name, and the City and State in which the AIRPORT is located. FLIGHT Each airline FLIGHT has a unique number, the Airline for the FLIGHT, and the Weekdays on which the FLIGHT is scheduled For example, every day of the week except Sunday can be coded as X7. AIRPLANE For

32、 each AIRPLANE, the AirplaneId, Total number of seats, and TYPE are kept. AIRPLANE_TYPE For each AIRPLANE TYPE (for example, DC-10), the TypeName, manufacturing Company, and Maximum Number of Seats are kept. The AIRPORTs in which planes of this type CAN LAND are kept in the database.,飛航預約系統的系統分析 (1/

33、3),資料庫管理,61,FLIGHT_LEG A FLIGHT is composed of one or more FLIGHT LEGs For example, flight number CO1223 from New York to Los Angeles may have two FLIGHT LEGs: leg 1 from New York to Houston and leg 2 from Houston to Los Angeles. Each FLIGHT LEG has a DEPARTURE AIRPORT and Scheduled Departure Time,

34、and an ARRIVAL AIRPORT and Scheduled Arrival Time. LEG_INSTANCE A LEG INSTANCE is an instance of a FLIGHT LEG on a specific Date For example, CO1223 leg 1 on July 30, 1989. The actual Departure and Arrival AIRPORTs and Times are recorded for each flight leg after the flight leg has been concluded. T

35、he Number of available seats and the AIRPLANE used in the LEG INSTANCE are also kept.,飛航預約系統的系統分析 (2/3),資料庫管理,62,RESERVATION The customer RESERVATIONs on each LEG INSTANCE include the Customer Name, Phone, and Seat Number(s) for each reservation.,飛航預約系統的系統分析 (3/3),資料庫管理,63,BANK資料庫的ER圖,資料庫管理,64,Each

36、BANK has a unique Code, as well as a Name and Address. Each BANK is related to one or more BANK-BRANCHes, and the BranhNo is unique among each set of BANK-BRANCHes that are related to the same BANK. Each BANK-BRANCH has an Address. Each BANK-BRANCH has zero or more LOANS Each BANK-BRANCH has zero or

37、 more ACCTS.,BANK資料庫的系統分析 (1/2),資料庫管理,65,Each ACCOUNT has an AcctNo (unique), Balance, and Type and is related to exactly one BANK-BRANCH and to at least one CUSTOMER. Each LOAN has a LoanNo (unique), Amount, and Type and is related to exactly one BANK-BRANCH and to at least one CUSTOMER. Each CUSTO

38、MER has an SSN (unique), Name, Phone, and Address, and is related to zero or more ACCOUNTs and to zero or more LOANs.,BANK資料庫的系統分析 (2/2),資料庫管理,66,COMPANY資料庫的ER圖,資料庫管理,67,An employee may work in up to two departments or may not be assigned o any department. Each department must have one and may have

39、up to three phone numbers. Each department can have anywhere between 1 and 10 employees. Each phone is used by one, and only one, department. Each phone is assigned to at least one, and may be assigned to up to 10 employees. Each employee is assigned at least one, but no more than 6 phones.,COMPANY資

40、料庫的系統分析,資料庫管理,68,COMPANY資料庫的(min, max) ER圖,資料庫管理,69,COURSE資料庫的ER圖,資料庫管理,70,A course may or may not use a textbook A text by definition is a book that is used in some course. A course may not use more than five books. Instructors teach from two to four courses. Each course is taught by exactly one in

41、structor. Each textbook is used by one and only one course. Add the relationship ADOPTS between INSTRUCTOR and TEXT An instructor does not have to adopt a textbook for all courses. An instructor does not adopt more than three textbooks for each course.,COURSE資料庫的系統分析,資料庫管理,71,COURSE資料庫的(min, max) ER圖,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 其他


经营许可证编号:宁ICP备18001539号-1