108 調查局特考三等 資訊科學組 資料庫應用 考古題詳解

核心觀念

本題考查三種資料庫定義的用途與差異：

• 主鍵（primary key）：唯一識別資料列，不可重複，也不可為 NULL。
• 外來鍵（foreign key）：限制欄位值必須符合被參照表格的鍵值，以維持參照完整性；在本題中，學生的系名必須對應到系所表中已存在的系名。
• 索引（index）：協助資料庫快速尋找資料列，通常能提升查詢效率；索引不等同於主鍵，也不會自行保證欄位值唯一，除非建立的是唯一索引。

解題方法

先區分題目描述的需求：主鍵用來判斷資料列是否有唯一識別值；外來鍵用來檢查跨表關聯是否一致；索引則用來加速查詢。再依欄位在資料模型中的角色判斷是否適合設定。

（一）將 student.ID 定義為主鍵

贊同。

學號 ID 用來識別每一位學生，適合作為學生表的主鍵。主鍵要求每位學生的 ID 都唯一且不為空，因此可避免兩筆學生資料具有相同學號，也可避免學生資料沒有識別值。

此設定的前提是：系統確實保證每位學生有唯一學號，且不會以 NULL 表示學號缺漏。若學號在資料制度中可能重複或缺漏，就不符合主鍵條件，必須另選能唯一識別學生的欄位或組合鍵。

（二）將 student.dname 定義為外來鍵

贊同。

題目已將 department.dname 定義為系所表的主鍵，因此可將 student.dname 設為外來鍵，參照 department.dname。

核心觀念

本題考查 SQL 的分組彙總、表格連結，以及子查詢篩選。

• GROUP BY：依指定欄位分組，通常搭配 COUNT 等彙總函數。
• JOIN：依兩表共同的欄位連結資料；本題以 IID 對應老師。
• IN (subquery)：判斷某欄位的值是否屬於子查詢所回傳的集合。
• 字串型態的欄位值須以單引號表示，例如 '106'、'張三'。

解題方法

（一）列出每個系的系名與授課老師個數

先由 instructor 取得老師所屬系別，再依 dname 分組並計算各組老師筆數。由於題目問的是老師個數，計數對象是 instructor 的資料列。

SELECT dname, COUNT(*) AS teacher_count
FROM instructor
GROUP BY dname;

此查詢以每位老師在 instructor 表中的一筆資料計數。若同一位老師可能在表中重複出現，才需改用 COUNT(DISTINCT IID)；依題目所述的主鍵設定，IID 唯一，因此 COUNT(*) 即可。

（二）列出「張三」老師於 106 學年度開設的所有課程代碼

先從 instructor 找出姓名為「張三」的老師編號，再與 teach 依 IID 連結，並篩選授課學年度為 '106' 的紀錄。題目要求課程代碼，因此只輸出 CID。

核心觀念

本題考查 ER 模式中的實體集合、關係集合、屬性、主鍵、數量限制，以及 EER 模式中的特化／一般化。

• 員工與交通工具是兩個實體集合，分別以員工編號、牌照號碼作為主鍵。
• 員工使用交通工具形成「使用」關係；每次使用都要記錄日期。
• 同一位員工可以多次使用同一台交通工具，因此必須讓不同日期的使用紀錄能區分開來。
• 交通工具分為汽車與摩托車，適合以 EER 的特化表示，並將各子類專屬屬性放在對應子類中。

解題方法

1. 找出實體集合與屬性

由題目需求可整理如下：

汽車與摩托車是交通工具的子類，子類會繼承交通工具的主鍵及共同屬性，因此不必另外建立不同的主鍵。

2. 建立使用紀錄並決定主鍵

若只將「使用日期」作為員工與交通工具之間二元關係的單一屬性，無法清楚表示同一員工與同一台車在不同日期的多次使用。因此將每次使用表示為一筆使用紀錄，並以員工、交通工具及使用日期共同識別：

這符合題目以日期記錄每次使用的粒度。若實務上同一員工同一天可能多次使用同一台交通工具，則題目所給欄位不足以區分那些紀錄，需另加使用序號或更精確的使用時間。

3. 判定數量限制

每筆使用紀錄必須對應一位員工及一台交通工具；一位員工可以有零筆或多筆使用紀錄，一台交通工具也可以有零筆或多筆使用紀錄。

因此，從員工及交通工具兩側看，使用紀錄數量皆為 $0..N$；從每筆使用紀錄看，員工與交通工具各為 $1$。

題目沒有規定所有員工都必須使用交通工具，也沒有規定每台交通工具都必須被使用，因此員工與交通工具對使用紀錄皆採部分參與。

4. 決定特化限制

依題意，交通工具分為汽車和摩托車。以下圖示採用兩類互斥且涵蓋全部交通工具的假設：每台交通工具恰屬於其中一類。若題目未意指這兩類已涵蓋所有交通工具，涵蓋限制則須依實際需求另行指定。

ER／EER 圖

核心觀念

本題考查「大數據」與傳統關聯式資料庫在資料特性及處理方式上的差異，以及資料庫選型時應如何依照工作負載作判斷。大數據通常以 Volume（資料量）、Velocity（資料產生與處理速度）、Variety（資料多樣性） 三項特性概括，稱為 3V。

大數據不等於單純「資料筆數很多」；資料的產生速度、格式多樣性及處理需求，也會影響儲存架構與分析方法。資料量多寡亦沒有固定的絕對門檻，應視組織所需的儲存、查詢與運算能力而定。

（一）大數據與傳統資料庫資料的三項差異

1. Volume：資料量龐大

大數據所處理的資料量通常大到單一伺服器或傳統資料庫難以有效儲存、索引與分析，因而需要透過多台機器分散儲存及平行處理。

例如，政府機關長期累積的網路紀錄、感測器資料或大量影像檔案，總量可能達到 TB、PB 等級。傳統關聯式資料庫也能儲存大量資料，但當容量與查詢負載超出單機資源時，擴充、維運及效能調整的成本會增加。

2. Velocity：資料產生與處理速度快

大數據常由線上服務、交易系統、網路設備及感測器持續產生，資料不僅量大，也可能要求即時或近即時地接收、處理及分析。

例如，網路安全監控系統必須快速分析大量連線紀錄，以辨識異常行為。傳統批次處理適合定期彙整資料，但若需求是持續接收資料並迅速回應，就需要能支援高吞吐量與串流或近即時處理的架構。

3. Variety：資料格式與來源多樣

傳統關聯式資料庫主要處理具有明確欄位與固定結構的資料，通常在寫入前便要定義資料表結構。大數據則可能包含多種來源與型態：

• 結構化資料：例如表格中的姓名、日期與交易金額。
• 半結構化資料：例如 JSON、XML、系統紀錄。
• 非結構化資料：例如文字、圖片、影音與文件。

資料格式多樣時，若一開始就強制套用固定資料表結構，可能增加資料轉換及模式調整的成本；因此常見做法是依資料型態採用不同的儲存與處理工具。

（二）較適合處理大數據的軟體及理由

解題方法

比較資料庫是否適合大數據，應從資料量、資料輸入速度、格式變化，以及擴充與查詢需求判斷。若題目所稱的大數據具有資料量大、持續高速寫入、來源與格式多樣等特徵，分散式 NoSQL 系統通常較適合承擔主要的儲存與大量讀寫工作；但這不代表所有大數據工作都應使用 NoSQL，也不表示關聯式資料庫已不適用。

NoSQL 適合之處

1. 支援水平擴充 資料可分散到多台伺服器，透過增加節點擴充儲存容量及運算能力，適合資料量與流量持續成長的情境。