112 高普考高考二級 資訊處理 高等資料庫設計 考古題詳解

核心觀念

本題考查 ER 模型的鍵、複合屬性、多值屬性、弱實體、關係屬性與基數限制，以及如何將 ER 圖轉換成關聯綱目。

• 實體若有題目指定的唯一屬性，可用該屬性作主鍵。
• 颱風沒有單一唯一屬性，但「年＋編號」組合唯一，因此以複合鍵識別。
• 一個屬性若包含多筆、各自有欄位的資料，應建成獨立關係；如路徑上的多個時間點。
• 屬於關係本身的資料，應放在該關係或其轉換後的關聯中；如颱風影響國家的死亡人數與經濟損失。
• 預測路徑由預測單位、颱風及預測時間共同識別，故其鍵包含這三者。

解題方法與假設

先依「是否能獨立識別」決定實體鍵，再將具有重複資料的路徑點拆成明細關係，最後依關係基數轉成外鍵或關係表。

題目沒有指定各關係的基數與參與限制，以下採用簡易且符合題意的假設：

1. 一個國家可有多個預測單位；每個預測單位隸屬一個國家。
2. 一個颱風可影響多個國家；一個國家也可受多個颱風影響。
3. 每個颱風可有多個實際路徑時間點；同一颱風的路徑時間點不重複。
4. 每筆預測路徑由一個預測單位針對一個颱風，在一個預測時間發布；每筆預測路徑可含多個預測路徑時間點，時間點在該預測路徑內不重複。
5. 人口、死亡人數、經濟損失及半徑等數值欄位皆假設為單值；若題目未給欄位型態，不另行指定。

（一）實體關係圖

以下以文字標示實體、主鍵、關係及基數；路徑點以明細實體表示。

國家 Nation
- nName（主鍵）
- population
- region
 1
 │ 隸屬
 │
 N
預測單位 Bureau
- bName（主鍵）
- startDate
- 所屬國家 → Nation

颱風 Typhoon
- year（主鍵之一）
- num（主鍵之一）
- cName
- eName
- startDate
 1 N
 │ 有實際路徑點 │
 └─────────────── 實際路徑點 TyphoonPoint
 - time（識別鍵之一）
 - latitude
 - longitude
 - radius
 識別鍵：颱風鍵＋time

颱風 Typhoon M ─── 影響（impact）─── N 國家 Nation
 - casualty
 - loss

預測單位 Bureau 1 ─── 發布／預測 ─── N 預測路徑 PredictedPath N ─── 針對 ─── 1 颱風 Typhoon
 - pTime
 - pPath
 識別鍵：預測單位＋颱風＋pTime
 │
 │ 1
 │ 包含預測路徑點
 │ N
 預測路徑點 PredictedPathPoint
 - time（識別鍵之一）
 - latitude
 - longitude
 - radius
 識別鍵：預測路徑鍵＋time

其中，預測路徑點是將 pPath 內多個時間點的資料拆開後表示；每個點皆屬於一筆特定預測路徑。impact 是颱風與國家之間的多對多關係，casualty 和 loss 描述的是這個「颱風影響某國」的事件，因此放在該關係上。

（二）關聯綱目

以下以 PK 標示主鍵、FK 標示外鍵；複合主鍵以括號中的多個欄位共同組成。

1. 國家

Nation(
 nName PK,
 population,
 region
)

nName 唯一，故作為主鍵。

2. 颱風

Typhoon(
 year PK,
 num PK,
 cName,
 eName,
 startDate
)

主鍵為複合鍵 (year, num)。題目指出其他屬性皆不唯一，不能以中文名、英文名或生成日期單獨識別颱風。

3. 颱風實際路徑點

核心觀念

本題考查候選鍵推導及第二、第三正規式（2NF、3NF）的分解。

• 超鍵：其屬性閉包可決定關聯中的所有屬性。
• 候選鍵：最小超鍵；刪除其中任一屬性後，都不再是超鍵。
• 2NF：符合 1NF，且每個非主屬性都完全相依於每一個候選鍵；不得只相依於複合候選鍵的一部分。
• 3NF：對每個非平凡函數相依 $X\rightarrow A$，至少符合下列一項：

1. $X$ 是超鍵；或
2. $A$ 是主屬性，也就是屬於某個候選鍵的屬性。

以下假設題目所列屬性皆為原子值，且函數相依僅採用題目明列者及其推論結果。

（一）推導關聯鍵

令「評論次序」為 $C$、「評論回覆次序」為 $R$，其餘屬性以題目名稱表示。

先觀察函數相依右側沒有出現的屬性：

$$URL,\ C,\ R$$

因此，任何候選鍵都必須包含這三個屬性；它們無法由其他屬性推導出來。

計算 $\{URL,C,R\}$ 的屬性閉包：

1. 由 $URL\rightarrow\text{標題},\text{發布者}$，可得標題及發布者。
2. 由 $\text{發布者}\rightarrow\text{訂閱數}$，可得訂閱數。
3. 由 $\{URL,C\}\rightarrow\{\text{評論者},\text{評論內容},\text{評論推數},\text{評論噓數}\}$，可得評論資料。
4. 由 $\{URL,C,R\}\rightarrow\{\text{回覆者},\text{回覆內容},\text{回覆推數},\text{回覆噓數}\}$，可得回覆資料。

故 $\{URL,C,R\}$ 可決定 VideoClip 的所有屬性，是超鍵。由於三者都必須包含於任何候選鍵，且其本身已足以決定全部屬性，因此它是最小超鍵。

關聯鍵（候選鍵）：

$$\boxed{\{URL,\text{評論次序},\text{評論回覆次序}\}}$$

這三個屬性是主屬性，其餘屬性都是非主屬性。

（二）分解為 2NF、但不滿足 3NF

解題方法

以複合候選鍵 $\{URL,C,R\}$ 為基礎，找出非主屬性對候選鍵真子集的部分相依：

• $URL\rightarrow\text{標題},\text{發布者}$，而 $\text{發布者}\rightarrow\text{訂閱數}$，所以 $URL\rightarrow\text{訂閱數}$ 亦成立。
• $\{URL,C\}\rightarrow$ 評論相關非主屬性。

這些相依違反 2NF，應分別拆出以相依決定項為鍵的關聯。回覆屬性則依賴完整鍵 $\{URL,C,R\}$，保留在回覆關聯中。

分解結果

關聯綱目	主鍵（PK）	外鍵（FK）
影片（$URL$，標題，發布者，訂閱數）	$URL$	無
評論（$URL,C$，評論者，評論內容，評論推數，評論噓數）	$\{URL,C\}$	$URL\rightarrow$ 影片（$URL$）

核心觀念

本題考查 SQL 的日期範圍條件、資料表連結、分組彙總，以及找出彙總值最大者。

• User 儲存使用者資料；Product 儲存商品資料；Opinion 儲存使用者對商品的評論。
• Opinion(uId) 參照 User，因此可透過 uId 連結評論與使用者。
• Opinion(pId, seller) 參照 Product，因此應以 pId 和 seller 兩欄一起連結評論與商品。
• 「2023 年」以日期範圍表示為大於等於 2023 年 1 月 1 日，且小於 2024 年 1 月 1 日。使用半開區間可涵蓋全年日期與時間值。

解題方法與 SQL

（一）列出 2023 年加入的使用者編號和姓名

在 User 表以 date 篩選加入日期，再投影出 uId 與 name。

SELECT uId, name
FROM User
WHERE date >= '2023-01-01'
 AND date < '2024-01-01';

（二）列出商品名稱為「掃地機器人」在 2023 年的總評論數

評論資料位於 Opinion，商品名稱則位於 Product，因此先依外鍵欄位 (pId, seller) 連結兩表，再篩選商品名稱與評論日期，最後以 COUNT(*) 計算評論筆數。

SELECT COUNT(*) AS total_comments
FROM Opinion AS O
JOIN Product AS P
 ON O.pId = P.pId
 AND O.seller = P.seller
WHERE P.name = '掃地機器人'
 AND O.time >= '2023-01-01'
 AND O.time < '2024-01-01';

此查詢回傳符合條件的評論總筆數；即使沒有符合的評論，COUNT(*) 仍會回傳一列，數值為 0。

（三）找出在 2023 年對「掃地機器人」做出最多評論的使用者之編號和姓名

核心觀念

本題考查非關聯式資料庫（NoSQL）的資料模型與特性。鍵值資料庫、文件資料庫、圖資料庫是常見的資料模型分類；「NoSQL 資料庫」則是涵蓋多種非關聯式資料模型的總稱，並非與前三者互斥的單一資料模型。

解題方法

依各資料庫的資料如何表示、如何查詢來說明，再搭配實際系統範例：

• 鍵值資料庫：以唯一鍵查找對應的值。
• 文件資料庫：以文件為單位儲存具階層結構的資料，常見格式包括 JSON、BSON。
• 圖資料庫：以節點和關係表示資料，適合處理多層關聯。
• NoSQL 資料庫：說明其相對於傳統關聯式資料庫的整體特徵，並指出前三種都是其常見類型。

各項說明

（一）鍵值資料庫（Key-value database）

以唯一的「鍵」（key）對應一個「值」（value），資料存取主要透過鍵進行。值通常被視為整體，資料庫不一定理解其內部欄位；因此，依鍵查詢與更新通常直接，但要依值內部條件搜尋或進行複雜關聯查詢，能力較受限。

真實系統範例：Redis。 Redis 可用鍵值方式儲存工作階段資料、快取或計數器。

（二）文件資料庫（Document database）

以文件作為儲存與查詢單位，文件常採 JSON 或 BSON 等格式，能包含欄位、巢狀物件與陣列。不同文件不必完全採用相同欄位結構，適合欄位變動較頻繁或資料具有階層結構的應用。

真實系統範例：MongoDB。 MongoDB 以 BSON 文件儲存資料，並支援依文件欄位建立索引及查詢。

（三）圖資料庫（Graph database）