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

《使用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)：利用高階概念資料庫模型來為資料庫建立概念綱要(conceptu

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

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

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

5、庫管理,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.多值屬性單值(single-valued)：屬性只有單一的值例如，Age(年齡)是人的單值屬性多值(multival

6、ued)：屬性可以有一組或多個值例如，汽車的Colors(顏色)屬性，某人的College_degrees(大學學位)屬性,屬性的型態(2/4),資料庫管理,13,屬性的型態(3/4),內儲屬性 vs.衍生屬性例如，Age(年齡)和Birth_date(生日)是人的兩個屬性然而，Age的值是由今天的日期和人的Birth_date屬性值一起決定的Birth_date屬性便是內儲屬性(stored attribute)Age屬性則是衍生屬性(derived attribute)複雜屬性(Complex attribute)例如，人的實體中有一個address_phone屬性某人有超過一個以上的住所

7、，而且每個住所都有好幾支電話其中Phone和Address兩者本身都是複合屬性,資料庫管理,14,屬性的型態(4/4),空值(NULL)：實體的某個屬性可能沒有任何適合的值例如，College_degrees這個屬性只適用於有大學學位的人空值的發生可能是下列情形之一不適用(not applicable)：沒有大學文憑的人，其College_degrees是NULL未知(unknown)：存在卻找不到(Exists but is missing)某個人的Height(身高)屬性為NULL不知道(Not known)某個人的Home_phone(家裡電話)屬性為NULL,資料庫管理,15,實體型態

8、(entity type)：定義相同屬性的實體集合。例如EMPLOYEE實體型態或PROJECT實體型態實體集合(entity set)：在資料庫中，任何時間點某個特定的實體型態的所有實體的集合,實體型態與鍵值屬性(1/4),資料庫管理,16,實體型態與鍵值屬性(2/4),鍵值屬性(key attribute)：是實體型態的某個或多個屬性，其值與集合中其他個別的實體都不相同。例如，EMPLOYEE的Ssn它的值可用來確認每個實體的唯一性鍵值屬性可能是複合的。例如，Registration是CAR實體型態的鍵值，它是由 Number和State所組成的複合鍵值弱實體型態(weak entity)

9、：實體型態沒有任何的鍵值，則稱之。,資料庫管理,17,實體型態與鍵值屬性(3/4),一個實體型態可能會有一個以上的鍵值。例如，CAR實體型態可能會有兩個鍵值：Vehicle_id 與Registration屬性,資料庫管理,18,實體型態與鍵值屬性(4/4),定義域(domain)：指派給實體型態中簡單屬性的資料值集合(value set)資料值集合一般是以資料型態(data type)來定義，例如整數(integer)、字串(string)、布林值(boolean)、浮點數(float)、列舉(enumerated)型態、日期/時間等。,資料庫管理,19,COMPANY資料庫的初步設計(1/

10、2),根據前面的需求，可先找出四種實體型態DEPARTMENT：屬性：Name、Number、Locations、Manager 和Manager_start_date其中Location是多值屬性因為Name與Number都是唯一的，所以我們可以指定Name與Number其中之一為鍵值屬性PROJECT：屬性：Name、Number、Location 和 Controlling_departmentName與Number其中之一可為鍵值屬性,資料庫管理,20,COMPANY資料庫的初步設計(2/2),EMPLOYEE：屬性：Name、Ssn、Sex、Address、Salary、Birth_

11、date、Department 和 Supervisor其中Name與Address可能為複合屬性(需與使用者再次溝通確認)。例如，Name 可能包含First_name、Middle_initial、Last_nameDEPENDENT：屬性：Employee、Dependent_name、Sex、Birth_date 和 Relationship(與員工之間的關係),資料庫管理,21,實體型態的初步設計範例,資料庫管理,22,在二個或多個分開的實體間經常存在具有某種特定意義的關係。EMPLOYEE Franklin Wong負責管理Research DEPARTMENTEMPLOYEE J

12、ohn Smith工作於Productx計劃相同型態的關係組成一個關係型態(relationship type)WORKS_ON關係型態是EMPLOYEE實體與PROJECT實體之間的關連MANAGES關係型態是EMPLOYEE實體與DEPARTMENT實體之間的關連,關係與關係型態(1/3),資料庫管理,23,關係與關係型態(2/3),事實上，當實體的某個屬性參考到另一個實體型態時，就會有某些關係存在DEPARTMENT的Manager屬性參考到管理此部門的某位員工PROJECT的Controlling_department屬性參考到負責管理此計劃的部門EMPLOYEE的Supervisor

13、屬性參考到另一位員工(管理此員工的人)EMPLOYEE的Department屬性參考到員工所工作的部門,資料庫管理,24,關係型態的向度(degree)是指參與實體型態的個數。例如，MANAGES和WORKS_ON都是二元(binary)關係型態在相同的一組參與的實體型態中，可以存在一個以上的關係型態例如，MANAGES與WORKS_FOR是EMPLOYEE與DEPARTMENT之間的兩個不同的關係，它們的意義不同，關係實例也不同,關係與關係型態(3/3),資料庫管理,25,WORKS_FOR關係型態的關係實例,資料庫管理,26,WORKS_ON關係型態的關係實例,資料庫管理,27,關係型態與

14、關係集合,關係型態(relationship type)是一個關係的綱要描述(schema description)確認關係名稱和參與的實體型態確認某些關係限制關係集合(relationship set)資料庫中關係實例(relationship instance)的目前集合關係型態的目前狀態在ER圖中，表示關係型態的方式如下菱形方塊用來表示關係型態以直線連接參與的實體型態,資料庫管理,28,依關係修訂COMPANY資料庫,在所有實體型態中，共存在六個二元關係(binary relationship)WORKS_FOR(在EMPLOYEE和DEPARTMENT間)MANAGES(在EMPLOY

15、EE和DEPARTMENT間)CONTROLS(在DEPARTMENT和PROJECT間)WORKS_ON(在EMPLOYEE和PROJECT間)SUPERVISION(在EMPLOYEE和EMPLOYEE間)DEPENDENTS_OF(在EMPLOYEE和DEPENDENT間),資料庫管理,29,關係型態的討論,在精製過程中，某些原始實體型態中的屬性會成為關係(參考圖3.8)DEPARTMENT的Manager MANAGESEMPLOYEE的Works_on WORKS_ONEMPLOYEE的Department WORKS_FORetc.同一組參與關係的實體間，可能存在一個以上的關係型態

16、，例如：MANAGES和WORKS_FOR是實體EMPLOYEE和DEPARTMENT間兩個不同的關係型態,資料庫管理,30,角色名稱與遞迴關係,每個參與關係型態的實體型態，在關係中會扮演特定的角色(role)例如，在關係WORKS_FOR中，EMPLOYEE扮演員工或工作者的角色，而DEPARTMENT則扮演部門或雇主的角色同樣的實體可能會以不同的角色參與關係型態例如，EMPLOYEE在SUPERVISION關係中參與了兩次：一次是主管的角色，一次是下屬的角色圖3.11中，標記1的線段代表主管的角色，而標記2的線則代表下屬的角色。,資料庫管理,31,遞迴關係的範例,資料庫管理,32,基數比(

17、cardinality ratio)：代表一個實體所能參與的關係實例的最大個數。二元關係型態基數比的可能值：一對一(1:1)：圖3-12一對多(1:N)或多對一(N:1)：圖3-9多對多(M:N)：圖3-13,關係型態的限制(1/3),資料庫管理,33,一對一的二元關係,資料庫管理,34,多對一的二元關係,資料庫管理,35,多對多的二元關係,資料庫管理,36,關係型態的限制(2/3),參與限制(participation constraint)：指定實體的存在是否依靠經由關係型態與另一實體產生關聯來決定也稱為最小基數限制(minimum cardinality constraint)零(可選擇

18、的，非存在相依性)一或多(強制的，存在相依性),資料庫管理,37,關係型態的限制(3/3),參與限制有兩種型態全部參與(total participation)實體型態中的每個實體至少要參與關係型態中的一個關係，如圖3-9也稱為存在相依性(existence dependency)在ER圖中，以雙線表示之部份參與(partial participation)並非實體型態中的所有實體都有參與關係型態中的一個關係，如圖3-12在ER圖中，以單線表示之基數比和參與限制通常合稱為關係型態的結構限制(structural constraint),資料庫管理,38,關係型態也可以擁有屬性，例如WORKS_

19、ON關係的Hours屬性記錄某位EMPLOYEE在某個PROJECT上的工作時數MANAGES關係的Start_date屬性表示某個員工開始管理某個部門的日期關係型態的屬性在1:1關係型態中的屬性，可以移轉到其中任何一個參與的實體型態裡在1:N關係型態中的屬性，只能移轉到N這一邊的實體型態裡在M:N關係型態中的屬性，不能被移轉到實體型態裡,關係型態的屬性,資料庫管理,39,弱實體型態(weak entity type)：本身沒有鍵值屬性的實體型態強實體型態(strong entity type)：有鍵值屬性的正常實體型態弱實體型態必須參與某些實體型態才能存在這個被依賴的實體型態稱為識別(ide

20、ntifying)或擁有者(owner)實體型態弱實體的識別是依據以下的組合：弱實體型態的某個部份鍵(partial key)與識別實體型態相關聯的某個實體,弱實體型態(1/3),資料庫管理,40,弱實體型態(2/3),弱實體型態其識別關係一定會存在有全部參與限制不過，並不是所有的存在相依性都會產生弱實體型態例如，DRIVER_LICENSE(駕照)實體，它有自己的鍵值(License_number)，且不是弱實體型態，但除非它與某個PERSON實體相關，否則就無法存在DEPENDENT(眷屬)是弱實體兩個不同員工的眷屬可能在Name、Birth_date、Sex和Relationship中有

21、相同的值，但他們仍舊是不同的實體EMPLOYEE是它的識別實體型態識別關係型態為DEPENDENT_OFDEPENDENT的部份鍵是Name,資料庫管理,41,弱實體型態(3/3),在ER圖中的表示法弱實體型態：雙線矩形識別關係：雙線菱形部份鍵屬性：虛線(dashed line)或點線(dotted line),資料庫管理,42,進一步修訂COMPANY資料庫(1/4),MANAGES一個在EMPLOYEE和DEPARTMENT之間的1：1關係型態EMPLOYEE的參與為部份參與DEPARTMENT的參與為全部參與(假設每個部門一定要有一位經理)這個關係型態中有Start_date屬性WORK

22、S_FOR一個在DEPARTMENT和EMPLOYEE之間的1：N關係型態兩者都是全部參與,資料庫管理,43,進一步修訂COMPANY資料庫(2/4),CONTROLS一個在DEPARTMENT和PROJECT之間的1：N關係型態PROJECT的參與為全部參與DEPARTMENT的參與為部份參與(因為某些部門可能沒有負責管理任何專案)SUPERVISION一個在EMPLOYEE(主管角色)和EMPLOYEE(下屬角色)之間的1：N關係型態兩者都是部份參與(因為不是每個員工都是主管，而且不是每個員工都有主管),資料庫管理,44,進一步修訂COMPANY資料庫(3/4),WORKS_ON一個在EM

23、PLOYEE和PROJECT之間的M：N關係型態兩者都是全部參與(因為一個員工可以參與多個計劃，且好幾個員工可以同時參與相同的計劃)這個關係型態中有Hours屬性DEPENDENTS_OF一個在EMPLOYEE和DEPENDENT之間的1：N關係型態它是弱實體型態DEPENDENT的識別關係EMPLOYEE的參與為部份參與DEPENDENT則是全部參與,資料庫管理,45,進一步修訂COMPANY資料庫(4/4),指定完上述6個關係型態後，可將圖3.8的實體型態中部份屬性移除從DEPARTMENT中移除Manager和Manager_start_date從PROJECT中移除 Controlli

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

25、多只能管理(MANAGES)一個部門指定EMPLOYEE參與MANAGES關係的限制為(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類別圖

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

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

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

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

30、Code,the AIRPORT Name,and the City and State in which the AIRPORT is located.FLIGHTEach 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.AIRPLANEFor each AIRPLANE,the Air

31、planeId,Total number of seats,and TYPE are kept.AIRPLANE_TYPEFor 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/3),資料庫管理,61,FLIGHT_LEGA FLIGHT is

32、composed of one or more FLIGHT LEGsFor 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,and an ARRIVAL AIRPORT and Scheduled Arr

33、ival Time.LEG_INSTANCEA 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.The Number of available seats and the AIRPLANE

34、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 BANK has a unique Code,as well as a Name and Addres

35、s.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 more ACCTS.,BANK資料庫的系統分析(1/2),資料庫管理,65,Each ACCOUNT has

36、 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 CUSTOMER has an SSN(unique),Name,Phone,and Address,and is related to z

37、ero 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 up to three phone numbers.Each department can have anywhere between 1 an

38、d 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資料庫的系統分析,資料庫管理,68,COMPANY資料庫的(min,max)ER圖,資料庫管理,69,COURSE資料庫的ER圖,資料庫管理,70,A cours

39、e may or may not use a textbookA 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 instructor.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圖,