← 返回 DBM

Chapter 4：EER Data Model 練習題

6 道 ER Diagram 設計練習 — 從基礎到進階

0 / 15 題完成

Exercise #1：外送餐食訂購系統

設計一個外送餐食訂購系統的 ER Diagram。系統需管理員工、商店、餐點、訂單與儲值紀錄。

實體與屬性

  • Employee(eId, pId unique, name, birthday, department, balance, phones{多值})
  • Store(sName, address, phone, description)
  • FoodItem(fName, description, unitPrice, discount) — Store 的 weak entity
  • Order(date, description, salePrice) — Employee 的 weak entity，一天最多一筆
  • Deposit(dTime, amount) — Employee 的 weak entity
  • Order 包含多個 FoodItem，記載 num（數量）

1. Employee 的 phones 是多值屬性，一位員工可有多支電話。

2. FoodItem 以 fName 為 partial key，需透過所屬 Store 的 sName 才能唯一識別。

3. Order 以 date 為 partial key，每位員工每天最多一筆訂單，需透過 Employee 的 eId 識別。

4. Deposit 以 dTime 為 partial key，需透過 Employee 識別。

5. Order 與 FoodItem 之間是 M:N 關係，需記載數量 num。

Q1：以下哪個不是 weak entity？

  • FoodItem
  • Order
  • Store
  • Deposit
Store 有自己的 primary key sName，是 strong entity。FoodItem、Order、Deposit 都需依賴 owner entity 才能唯一識別，屬於 weak entity。

Q2：FoodItem 的完整識別鍵（identifying key）是什麼？

  • fName
  • sName + fName
  • eId + fName
FoodItem 是 Store 的 weak entity，partial key 為 fName，需加上 owner entity Store 的 PK sName 才能唯一識別。

Q3：Order 與 FoodItem 之間的關係 cardinality 為何？

  • 1:1
  • 1:N
  • M:N
一筆 Order 可包含多個 FoodItem，一個 FoodItem 也可出現在多筆 Order 中，因此是 M:N 關係，並記載 num。
Employee eId pId name birthday dept balance phones Places 1 Order N date desc salePrice Makes 1 Deposit N dTime amount Store sName address phone desc Sells 1 FoodItem N fName desc unitPrice discount Contains M N num
識別關係：
• Employee ──(Places)──▷ Order（1:N，Employee 為 owner）
• Employee ──(Makes)──▷ Deposit（1:N，Employee 為 owner）
• Store ──(Sells)──▷ FoodItem（1:N，Store 為 owner）
一般關係：
• Order ──(Contains)── FoodItem（M:N，屬性：num）
屬性標記：
• 底線 = PK、虛線底線 = partial key、紫色 = 多值屬性

Exercise #2：課程資料庫

設計一個大學課程管理系統的 ER Diagram，管理課程、教師、學生及作業項目。

實體與屬性

  • Course(cNo, cName, cDesc)
  • Teacher(tNo, tName, title, departments{多值})
  • Student(sId, sName, gender, bDate, email)
  • Item(iName, dueDate) — Course 的 weak entity
  • Teaches: Teacher M:N Course
  • Takes: Student M:N Course，記載 finalScore
  • 學生在 Item 上有 score

1. Teacher 的 departments 是多值屬性，一位教師可隸屬多個系所。

2. Item 是 Course 的 weak entity，iName 為 partial key。

3. Takes 關係上有屬性 finalScore，記錄學生在該課程的最終成績。

4. 學生在 Item 上的 score 是三方關係（Student-Item）或可建模為 Student 與 Item 的 M:N 關係。

Q1：Item 的 owner entity 是誰？

  • Teacher
  • Course
  • Student
Item（作業項目）是 Course 的 weak entity，需透過 Course 的 cNo + Item 的 iName 才能唯一識別。

Q2：finalScore 屬於哪裡？

  • Student 的屬性
  • Course 的屬性
  • Takes 關係的屬性
finalScore 取決於「哪位學生修哪門課」，是 Takes（Student M:N Course）關係上的屬性。

Q3：Teacher 與 Course 之間的 cardinality？

  • 1:1
  • 1:N
  • M:N
一位教師可教多門課，一門課也可由多位教師共同教授，因此 Teaches 是 M:N 關係。
Teacher tNo tName title depts Course cNo cName cDesc Teaches M N Student sId sName gender bDate email Takes N M finalScore Has 1 Item N iName dueDate Submits M N score
識別關係：
• Course ──(Has)──▷ Item（1:N，Course 為 owner）
一般關係：
• Teacher ──(Teaches)── Course（M:N）
• Student ──(Takes)── Course（M:N，屬性：finalScore）
• Student ──(Scores)── Item（M:N，屬性：score）

Exercise #3：拍賣網站

設計一個線上拍賣網站的 ER Diagram，管理會員、商品、分類、出價與交易。

實體與屬性

  • Member(mId, name, email, startDate)
  • Merchandise(seqNo, name, description, expired, bottomPrice) — Member 的 weak entity
  • Category(cId, description) — 階層式自我關聯
  • Bid(bId, price, dateTime)
  • Transaction: Member M:N Merchandise，記載 price

1. Merchandise 是 Member 的 weak entity，seqNo 為 partial key（同一會員的商品流水號）。

2. Category 有自我關聯（recursive relationship），表示分類的階層結構（父分類→子分類）。

3. Bid 記錄出價，與 Member 和 Merchandise 相關。

4. Transaction 是 Member（買家）與 Merchandise 之間的 M:N 關係，記載成交 price。

5. 注意：賣家是 Merchandise 的 owner（Member），買家透過 Transaction 關聯。

Q1：Merchandise 的完整識別鍵是什麼？

  • seqNo
  • mId + seqNo
  • cId + seqNo
Merchandise 是 Member 的 weak entity，partial key 為 seqNo，需加上 owner Member 的 PK mId 才能唯一識別。

Q2：Category 的自我關聯代表什麼？

  • Category 與 Member 的關係
  • 分類的階層結構（父子關係）
  • Category 與 Bid 的關係
Category 的 recursive relationship（自我關聯）表示分類可以有子分類，形成階層式樹狀結構。例如「電子產品」→「手機」→「智慧型手機」。

Q3：Transaction 關係上的屬性 price 代表什麼？

  • 商品底價
  • 出價金額
  • 成交價格
Transaction 是買家（Member）與 Merchandise 之間的交易關係，price 記錄的是最終成交價格，不同於 Bid 的出價或 Merchandise 的底價。
Member mId name email startDate Lists 1 Merchandise N seqNo name desc expired bottomPrice BelongsTo N Category 1 cId desc SubOf N 1 Bid bId price dateTime Places 1 N Receives 1 N Buys M (buyer) N price
識別關係：
• Member ──(Lists)──▷ Merchandise（1:N，Member 為 owner/賣家）
一般關係：
• Member ──(Transaction)── Merchandise（M:N，屬性：price，Member 為買家）
• Member ──(Places)── Bid（1:N）
• Merchandise ──(Receives)── Bid（1:N）
• Merchandise ──(BelongsTo)── Category（N:1）
自我關聯：
• Category ──(SubCategoryOf)── Category（N:1，階層結構）

Exercise #4：醫院掛號系統

設計一個醫院掛號系統的 ER Diagram，管理科別、醫師、看診時段、病患與掛號。

實體與屬性

  • Department(dNo, dName unique, dCat, startDate)
  • Doctor(dId, pId unique, name, birthday, position)
  • DiagnosisTime(startDateTime, capacity) — Doctor 的 weak entity
  • Patient(pNo, pId unique, name, sex, birthday)
  • 掛號：Patient M:N DiagnosisTime，記載 no（掛號序號）、estimatedTime
  • 每科有一位主任（Doctor 1:1 Department）

1. DiagnosisTime 是 Doctor 的 weak entity，startDateTime 為 partial key。

2. 掛號關係是 Patient 與 DiagnosisTime 的 M:N，帶有 no 和 estimatedTime 屬性。

3. Doctor 隸屬於 Department（N:1），每個 Department 有一位主任（1:1 關係）。

4. dName 和 pId 都是 unique constraint，但不是 PK。

Q1：DiagnosisTime 的完整識別鍵是什麼？

  • startDateTime
  • dId + startDateTime
  • dNo + startDateTime
DiagnosisTime 是 Doctor 的 weak entity，partial key 為 startDateTime，需加上 owner Doctor 的 PK dId 才能唯一識別。

Q2：「每科有一位主任」應如何建模？

  • 在 Department 加一個 chiefName 屬性
  • Doctor 與 Department 之間建立 1:1 的 Chiefs 關係
  • 在 Doctor 加一個 isChief boolean 屬性
「每科一位主任」是 Doctor 與 Department 之間的 1:1 關係（Chiefs），不應用屬性表示，因為這是兩個 entity 之間的語義關聯。

Q3：掛號關係上的 no 代表什麼？

  • 病患編號
  • 掛號序號（看診順序）
  • 科別編號
no 是掛號關係的屬性，代表該病患在該看診時段的掛號序號，用於決定看診順序。
Department dNo dName dCat startDate Doctor dId pId name birthday position BelongsTo 1 N Chiefs 1 1 Opens 1 DiagnosisTime N startDateTime capacity Patient pNo pId name sex birthday Registers M N no estimatedTime
識別關係：
• Doctor ──(Opens)──▷ DiagnosisTime（1:N，Doctor 為 owner）
一般關係：
• Doctor ──(BelongsTo)── Department（N:1）
• Doctor ──(Chiefs)── Department（1:1，主任關係）
• Patient ──(Registers)── DiagnosisTime（M:N，屬性：no, estimatedTime）

Exercise #5：擴充住院資訊（EERD）

在 Exercise #4 基礎上，加入 specialization/generalization 與住院管理。這是 Enhanced ER Diagram（EERD）的練習。

擴充內容

  • Doctor 分成三個子類（specialization）：
    　　Resident（住院醫師）— residenceDate，有 Mentor 關係
    　　AttendingDoc（主治醫師）— specialties{多值}
    　　ChiefDoc（主任醫師）— specialties{多值}, chargeDate
  • Mentor 關係：Resident 的 mentor 必須是 AttendingDoc 或 ChiefDoc
  • Inpatient 是 Patient 的子類（generalization），有 startDate
  • Room(rNo, loc)
  • Treats: AttendingDoc/ChiefDoc 1:N Inpatient
  • Assists: Resident 1:N Inpatient（可選）

1. Doctor 的 specialization 是 disjoint（d）— 一位醫師只能屬於一個子類。

2. Inpatient 是 Patient 的 partial specialization — 不是所有病患都住院。

3. Mentor 關係的 constraint：Resident 的 mentor 必須是 AttendingDoc 或 ChiefDoc，這是一個 union type 的概念。

4. Treats 是必要的（total participation for Inpatient），Assists 是可選的（partial）。

5. Inpatient 與 Room 之間有 StaysIn 關係。

Q1：Doctor 的 specialization 應該是 disjoint 還是 overlapping？

  • Disjoint — 一位醫師只能是一種角色
  • Overlapping — 一位醫師可同時是多種角色
Resident、AttendingDoc、ChiefDoc 是互斥的職級，一位醫師在同一時間只能屬於一個子類，因此是 disjoint specialization。

Q2：Inpatient 與 Patient 的關係是什麼？

  • Total specialization
  • Partial specialization（不是所有 Patient 都住院）
  • 它們是獨立的 entity
Inpatient 是 Patient 的子類，但不是所有病患都需要住院，因此是 partial specialization。Inpatient 繼承 Patient 的所有屬性。

Q3：Assists 關係中 Inpatient 的 participation 是？

  • Partial — 住院病患不一定有住院醫師協助
  • Total — 每位住院病患都必須有住院醫師協助
題目說 Assists 是「可選」的，因此 Inpatient 在 Assists 關係中是 partial participation（單線），不是每位住院病患都需要 Resident 協助。
Doctor d Resident residenceDate AttendingDoc specialties ChiefDoc specialties chargeDate Mentor N 1 Patient d Inpatient startDate Room rNo loc StaysIn N 1 Treats 1 N Assists 1 N (partial) d = disjoint | 單線 = partial specialization | 雙線 = total participation
Specialization（disjoint, total）：
• Doctor ──d──▷ {Resident, AttendingDoc, ChiefDoc}
Generalization（partial）：
• Patient ──▷ Inpatient
關係：
• Resident ──(Mentor)── AttendingDoc∪ChiefDoc（N:1）
• AttendingDoc/ChiefDoc ──(Treats)── Inpatient（1:N，total for Inpatient）
• Resident ──(Assists)── Inpatient（1:N，partial for Inpatient）
• Inpatient ──(StaysIn)── Room（N:1）

Exercise #6：ERD 製作工具

設計一個 ER Diagram 製作工具的後設模型（meta-model）。這個工具本身的資料結構也可以用 ER Diagram 來描述！

實體與屬性

  • EntityType(eName, color, location)
  • WeakEntityType(wName, color, location)
  • RelationshipType(rName, color, location, degree)
  • Attribute(aId, aName, domain, isSingleValued)
  • 複合屬性可包含多個 Attribute（自我關聯）
  • EntityType 有關鍵屬性（key attributes）、參與 RelationshipType
  • WeakEntityType 有識別關係（identifying relationship）、部分鍵屬性（partial key）
  • 參與度記載 max, min

1. 這是一個 meta-model：用 ER Diagram 來描述 ER Diagram 工具的資料結構。

2. Attribute 的自我關聯表示複合屬性（composite attribute）可包含子屬性。

3. EntityType 與 Attribute 之間有「HasAttribute」關係，其中某些是 key attribute。

4. EntityType 參與 RelationshipType，需記載 min/max cardinality。

5. WeakEntityType 需要一個 identifying RelationshipType 和 partial key Attribute。

6. 注意 EntityType 和 WeakEntityType 可考慮用 specialization 統一建模。

Q1：Attribute 的自我關聯代表什麼概念？

  • 多值屬性
  • 複合屬性（composite attribute）
  • 衍生屬性
Attribute 的自我關聯（recursive relationship）表示一個屬性可以包含多個子屬性，這就是複合屬性（composite attribute）的概念。例如 Address 包含 Street、City、Zip。

Q2：EntityType 參與 RelationshipType 時，min 和 max 記載在哪裡？

  • EntityType 的屬性
  • RelationshipType 的屬性
  • Participates 關係的屬性
min 和 max 取決於「哪個 EntityType 參與哪個 RelationshipType」，是 Participates（M:N）關係上的屬性。

Q3：WeakEntityType 的 identifying relationship 應如何建模？

  • WeakEntityType 的一個屬性
  • WeakEntityType 與特定 RelationshipType 之間的關係
  • RelationshipType 的一個屬性
WeakEntityType 需要透過一個 identifying RelationshipType 連結到 owner EntityType。這應建模為 WeakEntityType 與 RelationshipType 之間的關係（IdentifiedBy），而非屬性。
EntityType eName color location WeakEntityType wName color location RelationshipType rName color location degree Attribute aId aName domain isSingleValued Participates M N max min HasKey 1 N Identifying N 1 HasPKey 1 N ComposedOf 1 N HasAttr 1 N
關係：
• EntityType ──(HasAttribute)── Attribute（1:N）
• EntityType ──(HasKey)── Attribute（1:N，標記 key attributes）
• EntityType ──(Participates)── RelationshipType（M:N，屬性：min, max）
• WeakEntityType ──(HasAttribute)── Attribute（1:N）
• WeakEntityType ──(HasPartialKey)── Attribute（1:N）
• WeakEntityType ──(IdentifiedBy)── RelationshipType（N:1）
• RelationshipType ──(HasAttribute)── Attribute（1:N）
自我關聯：
• Attribute ──(Contains)── Attribute（1:N，複合屬性）

🏆 成就系統

答對題目解鎖成就！

🌱
初學者
答對第一題
🍱
外送達人
完成 Exercise 1
📚
學霸
完成 Exercise 2
🔨
拍賣高手
完成 Exercise 3
🏥
掛號專家
完成 Exercise 4
🧬
EER 大師
完成 Exercise 5
🛠️
Meta 建模師
完成 Exercise 6
💎
完美無瑕
全部答對（無錯誤）
👑
全制霸
完成所有 15 題

📖 術語表

Entity Type
實體類型。現實世界中可獨立存在的事物類別，如 Employee、Student。
Weak Entity Type
弱實體類型。無法僅靠自身屬性唯一識別，需依賴 owner entity 的 PK + 自身 partial key。用雙框表示。
Primary Key (PK)
主鍵。能唯一識別 entity 的最小屬性集合。在 ER 圖中以底線標示。
Partial Key
部分鍵。Weak entity 的屬性，需搭配 owner entity 的 PK 才能唯一識別。以虛線底線標示。
Relationship Type
關係類型。描述兩個或多個 entity 之間的關聯，如 Teaches、Takes。用菱形表示。
Identifying Relationship
識別關係。連結 weak entity 與其 owner entity 的關係。用雙菱形表示。
Cardinality
基數。描述關係中 entity 的參與數量比例，如 1:1、1:N、M:N。
Participation Constraint
參與限制。Total participation（雙線）表示每個 entity 都必須參與；Partial participation（單線）表示可選。
Multivalued Attribute
多值屬性。一個 entity 可有多個值的屬性，如 phones、departments。用雙橢圓表示。
Composite Attribute
複合屬性。可分解為更小子屬性的屬性，如 Address 分為 Street、City、Zip。
Derived Attribute
衍生屬性。可從其他屬性計算得出的屬性，如 age 可從 birthday 推算。用虛線橢圓表示。
Specialization
特殊化。將 superclass 分成多個 subclass 的過程（top-down）。如 Doctor → Resident, AttendingDoc, ChiefDoc。
Generalization
一般化。將多個 subclass 合併為 superclass 的過程（bottom-up）。與 specialization 方向相反。
Disjoint Constraint (d)
不相交限制。entity 只能屬於一個 subclass。用圓圈內的 d 表示。
Overlapping Constraint (o)
重疊限制。entity 可同時屬於多個 subclass。用圓圈內的 o 表示。
Total Specialization
完全特殊化。superclass 的每個 entity 都必須屬於某個 subclass。用雙線連接。
Partial Specialization
部分特殊化。superclass 的 entity 不一定屬於任何 subclass。用單線連接。
Recursive Relationship
遞迴關係（自我關聯）。同一個 entity type 扮演不同角色參與的關係，如 Category 的父子關係。
Union Type (Category)
聯合類型。subclass 的成員來自多個不同的 superclass 的聯集。用 ∪ 符號表示。
(min, max) Notation
最小-最大標記法。標示 entity 在關係中的參與次數範圍，如 (0,N) 表示可不參與或參與多次。