習題題庫 [第三章：實體關係模式-進階練習]
習題3-1
假設有一位資料庫分析師要設計一個上課系統，該系統包括學生、課程、老師，和教室四個實體型態，這位分析師想記錄哪位學生上哪一門課是哪一位老師教用哪一間教室，於是他用了一個如下的四元的關係型態來表示：

1. 請問這樣的表示法有何缺點？請用三個二元的關係型態來表示這位分析師想分析的關係。
2. 如果要表示兩兩實體型態間的關係，其實可以有六種二元關係型態 ( )，請問是哪六種？有必要在一個ERD 中繪出此六種關係型態嗎？為什麼？
 
習題3-2
假設你要設計一個課程資料庫應用系統。該系統可用來記載課程和其相關資訊。資料需求如下：
• 課程 (Course)：包括課程編號 (cNo)、課程名稱 (cName)，和課程敘述 (cDesc)。其中課程編號為唯一。
• 老師 (Teacher)：包括老師識別號 (tNo)、姓名 (tName)、職級 (title)，和所屬單位 (departments)。其中老師識別號為唯一。且一位老師會有一個或多個隸屬單位。此外一位老師可能教授 (Teaches) 多門課程，一門課程也可能有多位老師一起合授。
• 學生 (Sudent)：包括學號 (sId)、姓名 (sName)、性別 (gender)、生日 (bDate)，和 Email (email)。其中學號為唯一。此外，學生的修課 (Takes) 課程和學期成績 (finalScore) 必須記載。
• 計分項目 (Item)：包括名稱 (iName) 和繳交日期 (dueDate)。沒有唯一的屬性，不過對於每一個課程，其計分項目名稱必不同。此外，學生的計分項目上的分數 (score) 必須記載。

請依以上的需求，畫出 ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-3
假設你要替一個連鎖圖書館 (如台北市立圖書館或高雄市立圖書館) 設計流通系統，以用來記錄圖書和讀者借閱資訊。該館是由一些分館所組成，但為顧及讀者的方便和便於管理，採用同一套流通系統。該流通系統所需記錄的資料如下：
• 書 (Book)：包括分類號 (callNumber)、書名 (title)、作者姓名 (authorName)，和出版社 (publisher)。其中出版社又可細分出版社名稱 (name)、住址 address)，和電話 (phone)。且一本書的作者可能有多位。分類號為唯一。
• 書副本 (BookCopy) ： 一本書可能被購買好幾本， 每一紙本就叫做一個BookCopy，它有一個屬性流水號 (seqNum)，用來辨識同一本書的不同副本。
• 讀者 (Patron)：讀者需記載讀者編號 (patronId)、姓名 (name)、住址 (address)，和電話 (phone)。讀者編號為唯一。
• 分館 (LibraryBranch)：記載分館名稱 (branchName) 和住址 (address)。分館名稱為唯一。
此外，讀者與書副本間有兩個關係型態：借閱 (Borrows) 和預約 (Reserves)。
請注意一本書副本只能被一個讀者借閱，其借閱日期和到期日都要記載，並只能被一個讀者預約，而且我們不記載歷史性的資料。分館與書副本間也有一個關係型態：收藏 (Stores)。

請依以上的需求，畫出 ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-4
假設你要替遠距教學的互動功能設計一個系統，該系統記載課程資訊並可讓學生張貼文章到討論版。具體說來，該系統的資料需求如下：
• 學生 (Student)：包括學號 (sId)、姓名 (name)、性別(sex)、生日 (bDate)、畢業學校 (graduate)、和公司 (employer)。其中畢業學校可能有多個。學號為唯一。
• 課程 (Course)：包括課程編號 (cId) 和課程名稱(courseName)。其中課程編號為唯一。
• 老師 (Instructor)：包括老師 ID (iId)、姓名 (name)，和電話 (phone)。老師ID為唯一。
• 討論版 (Pforum)：包括版名 (pName) 和設立時間 (sDate)。討論版是屬於課程的，換句話說，某一課程的各討論版之版名必定不同。
• 文章 (Article)：包括流水號 (seq)、主題 (subject)，和內容 (content)。文章是屬於討論版的，換句話說，某一討論版的各文章之流水號必定不同。

此外，老師跟學生間有一個關係型態「修課」(Takes)，老師和課程間有一個關係型態「授課」(Teaches)，學生和文章間有一個關係型態「貼」 (Posts)。請注意我們只需描述現時的資料，不需描述歷史的資料，所以一門課只有一位老師教。

請依以上的需求，畫出ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-5
假設你要為一個人力資源部門設計徵才系統，該系統需記載公司裡的各個職位、空缺職位、應徵者的資料、以及面談結果。具體說來，該系統的資料需求如下：
1. 部門 (Department)：包括部門編號 (dId)、部門名稱(dName)，和部門所在(dLocations)，其中部門編號和部門名稱均唯一，且部門所在地可有多個。
2. 職位 (Position)：用來描述一個職位，包括職位名稱(pName) 和職責敘述 (pDesc)。其中沒有一個屬性是唯一的，但同一部門的各個職位的職位名稱必不同。
3. 職缺 (Vacancy)：包括職缺編號 (vId)、職缺條件 (vCond)、職缺人數 (vNo)， 和出缺日期 (vDate)。其中職缺編號為唯一。此外，一個職缺必對應於一個職位，但一個職位可能會分成數個職缺來報。
4. 應徵者 (Applicant)：包括身分證字號 (pId)、姓名 (name)、性別 (gender)、學歷 (degrees)，和其他資料 (data)。其中身分證字號為唯一，學歷可有多個。一個應徵者可以應徵多個職缺。
5. 員工 (Employee)：包括工號 (eId)、姓名 (name)、性別 (gender)，和專長(expertise)。其中工號是唯一，而專長可有多個。

此外，有些應徵者申請某個職缺時需要與某些員工面談(Interview)，面談的日期和面談的結果必須記載。請繪出符合以上資料需求的 ERD，必要時可以自行假設其他條件，但要寫清楚。
 
習題3-6
假設你要設計一個職棒聯盟的戰績系統，該系統可以記載球隊資訊和比賽記錄。具體說來，包含以下四個實體型態：
1. 球隊 (Team)
2. 聯盟 (League)
3. 球員 (Player)
4. 球場 (Field)
這四個實體型態有以下的性質：
• 每個球隊有隊名 (tName)、一個總教練 (chiefCoach)、數個教練 (coach)，和球隊所屬的公司名稱 (company)。教練的 ID (pId)、姓名 (cName) 和生日 (birthday) 需記載。每個球隊必須隸屬於剛好一個聯盟。其中隊名為唯一。
• 球隊的輸贏記錄需記載，包括勝隊、敗隊、比賽日期 (date)、比數 (result)，和比賽球場。其中勝隊、敗隊，和比賽日期合起來為唯一。假設沒有平手。
• 每一聯盟有名稱 (lName) 和成立日期 (startDate)。其中名稱為唯一。
• 每一球場有球場 ID (fId)、名稱 (fName)，和地址(address)。其中球場 ID 和名稱均為唯一。每一球隊有一主球場 (Home)。
• 球員有球衣號碼 (pNo)、姓名 (name)、生日 (birthday)、打擊率 (hitRate)，和月薪 (salary)。其中沒有任一屬性為唯一，但每一個球隊的球員之球衣號碼必然不同。每一球員必須隸屬於一球隊。

請依以上的需求，畫出ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-7
假設你要為一家小型工廠設計庫存系統，該系統可記載工廠的物料、進貨和領料資訊。具體說來，包含以下四個實體型態：
1. 進貨單 (Stock)：工廠進原料時須填進貨單。
2. 領料單 (Procurement)：工人領料製造時須填領料單。
3. 物料 (Part)：倉庫裡有數百種物料。
4. 供應商 (Supplier)：供應商供應物料。

這四個實體型態有以下的性質：
• 每一張進貨單有進貨單編號 (sNo) 和日期 (sDate)，其中進貨單編號為唯一。此外，進貨單上並記載數筆明細，每一明細記載一種物料和其進貨數量。
• 每一張領料單有領料單編號 (pNo) 和日期 (pDate)，其中領料單編號為唯一。此外，領料單上並記載數筆明細，每一明細記載一種物料和其領料數量。
• 每一物料有名稱 (name)、尺寸 (size)、顏色 (color)，和物料編號 (pId)。請注意該公司是一小型工廠，故物料編號乃沿用該物料供應商的物料編號，因此物料編號可能重複。但因每一種物料只由一供應商提供，因此供應商和物料編號的組合便是唯一。
• 每一供應商有供應商編號 (spNo)、公司名稱 (company)、住址 (address)、電話(phone)、傳真 (fax)，和負責人姓名 (contact)。請注意一家供應商可能有不只一個電話號碼。供應商編號為唯一。

請依以上的需求，畫出ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-8
假設你要為一錄影帶租借店設計資訊系統，該系統必須能記載影片的進貨和租借記錄。具體說來，包含以下五個實體型態：
1. 影片 (Video)：表示一部影片。
2. 影片拷貝 (VideoCopy)：表示一片光碟或一卷錄影帶，一個影片可有多個影片拷貝。
3. 會員 (Member)：表示一位會員。
4. 會員種類 (Type)：表示某類會員，比如永久會員、年會員、扣點會員等。
5. 影片代理商 (Agency)：表示一個代理商。

這五個實體型態有以下的性質：
• 影片：包括影片編號 (vNo)、片名 (title)、種類 (type，可能值為緊張、偵探、愛情、喜劇、戰爭、恐怖等) 等級(grade，可能值為Normal、X、R、PG13 ) 和導演 (director)。其中影片編號為唯一，且種類可能包括多個。
• 影片拷貝：包括流水號 (seq)、媒體種類 (media，可能值為VCR、VCD、DVD、LD 等)，和拷貝日期 (date)。其中沒有任一屬性是唯一，但對於同一影片之不同拷貝，流水號 + 媒體種類也不一樣。
• 會員：包括姓名 (name)、電話號碼 (phone)、住址 (address)、加入日期 (startDate)，和所剩點數 (credits)。其中姓名 + 電話號碼是唯一。此外，會員的會員種類必須要記載，且會員現在租借的影片拷貝也要記載。
• 會員種類：包括種類名稱 (mType，可能值為永久會員、年會員、扣點會員等)、會費 (fee)、總點數 (totalCredits)，和每片扣點數 (perCredits)。其中種類名稱為唯一。
• 影片代理商：代理商名稱 (aName)、電話 (phone)、負責人 (contact)、住址(address)，和統一編號 (uCode)。其中代理商名稱和統一編號均是唯一。代理商與影片間的供應關係必須記載。

請依以上的需求，畫出ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-9
問卷的設計和使用是了解顧客滿意度的一個很常用的方式。請設計一資料庫來儲存問卷的題目和調查結果。此資料庫的目的是支援設計者製作問卷、統計問卷，並讓使用者填寫問卷。經過初步的訪談，得到以下資料需求：
• 問卷 (Questionaire)：每一問卷有問卷 id (qId)、問題前文字 (prefix)、問題後文字 (postfix)、和問卷標題 (title)，其中問卷id 為唯一。
• 單選題 (Single_Question)：每一單選題有問題 id (sId)、問題敘述 (desc)、題號 (no)，和是否顯示 (visible)，其中沒有任一屬性為唯一，但同一問卷的不同問題之問題id 必不同。
• 選項 (Choice)：每一選項有選項號 (no) 和選項內容(content)，其中沒有任一屬性為唯一，但同一單選題之各個選項的選項號並不相同。
• 問卷填一次 (Session)：每一次填問卷會產生一個流水號 (seq) 和填寫日期(date)，其中沒有任一屬性為唯一，但同一問卷的不同Session 之流水號必不同。請注意每一 Session 會去回答所屬問卷之單選題，所填的答案要記載 (提示：可在 Session 和 Choice 之間建立一關係型態)。

請依以上的需求，畫出 ERD。必要的話，可自行假設其他相關狀況，但必須
 
習題3-10
假設你想為一拍賣網站設計一資料庫應用系統，該網站採會員制，會員可以在網站上拍賣產品，也可以在網站上叫價。為簡化程序和考慮公平性，拍賣是採offline 的方式 (非線上即時)。也就是說，對於一個拍賣產品，在截止時間前，都可以出價，但出價後就不可撤回。此拍賣網站資料庫系統的資料需求如下：
• 會員 (Member)：每一會員有會員 id (mId)、會員姓名 (name)、會員 email(email)，和加入日期 (startDate)，其中mId 為唯一。
• 拍賣商品 (Merchandise)：每一拍賣商品有流水號(seqNo)、商品名稱 (name)、商品敘述 (description)、拍賣截止日期時間 (expired)，和底價 (bottomPrice)。其中沒有任一屬性為唯一，但同一會員的不同拍賣商品之流水號必不同。此外，商品類別 (如下所示) 也要記載。
• 商品類別 (Category)：商品類別為階層式，每一商品類有商品識別號 (cId) 和商品類敘述 (description)，其中商品識別號為唯一。此外，每一商品類有一父商品類 (即在商品類階層的上一層，比如，咖啡的父商品類為飲料)。
• 叫價 (Bid)：儲存叫價紀錄。每一次叫價就有一叫價識別號 (bId)、叫價價格(price)，和叫價日期時間 (dateTime)，其中叫價識別號為唯一。此外，叫價的會員和叫價的商品也要記載。
此外，會員與拍賣商品間有一個關係型態為交易(Transaction)，並記載成交價(price)。

請依以上的需求，畫出 ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-11
假設你要設計一水電維修系統，該系統可以讓員工線上填維修申請單，並可記載維修記錄。其資料需求如下：
1. 員工 (Employee)：包括員工編號 (eId)、身分證字號 (pId)、姓名 (name)，和生日 (birthday)。其中員工編號和身分證字號均是唯一。
2. 單位 (Department)：包括單位名稱 (dName) 和單位所在地 (dLocation)。其中單位名稱是唯一。此外，一位員工必然屬於某個單位，但一個單位可有多名員工。
3. 故障通報單 (Malfunction)：包括通報單編號 (mNo)、通報日期 (mDate)，和通報明細 (mDetail)， 其中通報明細必須包括地點 (mLocation) 和問題描述(mProblem)，而通報單編號是唯一。此外，通報人 (是一位員工) 也必須記載。
4. 故障處理單 (Processing)：包括處理日期 (pDate) 和處理人 (是一位員工)，此外相對的故障通報單都必須記載。請注意一張故障通報單可能會有數張故障處理單 (因為一次處理不好)，但這些故障處理單的處理日期必然不同。
5. 庫存零件 (Part)：包括零件編號 (pNo)、零件名稱(pName)、和庫存數量 (quantity)。其中零件編號是唯一。此外，一張故障處理單可能會使用多種零件，每一種零件的使用數量也需記載。

請依以上需求畫出ERD，必要的話可自行假設其他相關狀況，但必須註明。
 
習題3-12
假設你要替一個餐廳設計點菜系統，該系統記載餐點資訊並可以讓顧客訂位。其資料需求如下：
• 單點 (Dish)：包括單點編號 (dNo)、單點名稱 (dName)、單點敘述 (dDesc)，和價錢 (dPrice)。其中單點編號和單點名稱均為唯一。
• 套餐 (Set)：包括套餐編號 (sNo)、套餐名稱 (sName)、套餐敘述 (sDesc)，和價錢 (sPrice)。其中套餐編號和套餐名稱均為唯一。顧名思義，套餐就是由數個單點所組成，組成的單點和單點數量必須記載。
• 餐桌 (Table)：包括餐桌編號 (tId)、容納人數 (capacity)，和位置 (location)。其中餐桌編號為唯一。
• 服務生 (Waiter)：包括姓名 (name) 和性別 (sex)。其中姓名為唯一。此外，每一服務生都必須有剛好一位代理服務生 (Substitute)，以便該服務生不在時可以頂替其工作。
• 顧客 (Customer)：包括顧客姓名 (cName)、日期時間 (dateTime)、人數 (num)，和消費金額 (payment)。其中沒有任何屬性是唯一的，但每一顧客一定被分配一張餐桌，使用同一餐桌的顧客其日期時間 (dateTime) 必然不同。請注意，為了環境美觀，本餐廳不允許併桌，也就是說每一顧客只有佔用一張餐桌。
• 每一顧客所點的餐點可能包括數個單點和數個套餐，顧客的點餐記錄 (包括種類和數量) 要記載。
• 每一服務生負責數個餐桌，每一餐桌剛好有一位服務生負責。

請依以上的需求，畫出ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-13
假設你要替一家醫院設計掛號系統。該系統記載醫師相關資訊並可以讓病人預約掛號。其資料需求如下：
• 科別 (Department)：包括科編號 (dNo)、科名稱 (dName)、科類別 (dCat)，和成立日期 (startDate)。其中科編號和科名稱均為唯一。
• 醫師 (Doctor)：包括醫師編號 (dId)、姓名 (name)、生日 (birthday)、身分證字號 (pId)，和職級 (position)。其中醫師編號和身分證字號均為唯一。一位醫師必定隸屬於某一科，且每一科都有一位主任。
• 看診時段 (DiagnosisTime)：包括看診開始時間(startDateTime) 和人數限制(capacity)。一個看診時段只屬於一位醫師，每一位醫師都有好幾個看診時段，但一位醫師的各個看診時段的開始時間都不相同。
• 病人 (Patient)：包括病歷號 (pNo)、姓名 (name)、性別 (sex)、生日 (birthday)，和身分證字號 (pId)。其中病歷號和身分證字號均為唯一。病人可以選擇某位醫生的某個看診時段來預約掛號，掛號時會得到一個號碼 (no) 和預計看診時間(estimatedTime)，這些都必須記載。

請依以上的需求，畫出ERD。必要的話，可自行假設其他相關狀況，但必須寫清楚。
 
習題3-14
假設你要設計一個ERD 的製作工具軟體，該軟體可以將使用者所繪的ERD元素存在資料庫裡，你的任務是替該 ERD 製作工具軟體作資料庫設計。因此你需要將該軟體的資料需求繪製成 ERD。仔細分析之後，你發現該 ERD 應包括以下數個實體型態：
1. EntityType：用來描述所有的實體型態。
2. WeakEntityType：用來描述所有的弱實體型態。
3. RelationshipType：用來描述所有的關係型態。
4. Attribute：用來描述所有的屬性 (可能是實體型態或關係型態的屬性)。

你的ERD 應該滿足以下性質：
• 每一個實體型態 (EntityType) 有名稱 (eName)、顏色(color)，和位置 (location)，其中名稱為唯一。
• 每一個實體型態 (EntityType) 會有數個屬性，並可以參與數個關係型態。
• 每一個實體型態 (EntityType) 必定有一個或多個關鍵屬性
• 每一個弱實體型態 (WeakEntityType) 有名稱 (wName)、顏色 (color)，和位置(location)，其中名稱為唯一。
• 每一個弱實體型態 (WeakEntityType) 會有數個屬性，並可以參與數個關係型態。
• 每一個弱實體型態 (WeakEntityType) 至少會有一個識別關係型態。
• 每一個弱實體型態 (WeakEntityType) 可以有一個部分鍵屬性。
• 每一個關係型態 (RelationshipType) 會有名稱 (rName)、顏色 (color)、位置(location)，和參與實體型態個數 (degree)。其中名稱為唯一。
• 一個關係型態 (RelationshipType) 至少會有一個參與的實體型態。
• 每一個實體型態和所參與的關係型態上要記載其最大參與度 (max) 和最小參與度 (min)。
• 每一個屬性 (Attribute) 有屬性 id (aId)、名稱 (aName)、定義域 (domain)，和是否單值 (isSingleValued)。
• 複合屬性可以包括數個屬性。