民國115年 高考三級 資訊處理 資料庫應用考古題

民國115年 高考三級 資訊處理 資料庫應用收錄考選部官方試題，共 4 題可線上瀏覽，考選部未公告本科目答案。

官方資料

題目與答案

第1題

隨著資安威脅與法規合規性（如ISO 27001）要求提升，資料庫稽核 （Database Audit）成為確保數據完整性的關鍵機制。假設現有用於記錄 該稽核數據之關聯式資料庫，其資料表及內容敘述如下： 稽核政策(政策編號, 政策名稱, 物件名稱, 物件類型, 稽核動作, 是否啟用, 建立者編號) 政策編號為PK；物件類型之內容值可為「TABLE」、「VIEW」、 「STORE PROCEDURE」、「FUNCTION」之英文；稽核動作之內容 值可為「SELECT」、「INSERT」、「UPDATE」、「DELETE」等指令。 稽核日誌(日誌編號, 政策編號, 操作時間, 操作類型) 日誌編號為PK；政策編號為FK，參考「稽核政策」表中的政策編號。 異常事件(事件編號, 日誌編號, 嚴重程度, 偵測時間, 事件描述, 是否已結案) 事件編號為PK；日誌編號為FK，參考「稽核日誌」資料表的日誌編 號；嚴重程度之內容值可為「高」、「中」、「低」；是否已結案之內容 值為「Y」或「N」。 稽核人員(稽核人員編號, 姓名, 所屬部門) 稽核人員編號為PK。 事件處理紀錄(處理編號, 事件編號, 稽核人員編號, 處理日期) 處理編號為PK；事件編號為FK，參考「異常事件」資料表中的事件 編號；稽核人員編號為FK，參考「稽核人員」資料表的稽核人員編號。 請回答下列問題，其中 至 請使用SQL 語法進行作答。 請透過上述關聯式綱目畫出實體關聯式模型（Entity-Relationship Model, ER Model）。（10 分） 查詢各嚴重程度異常事件的統計資訊，列出嚴重程度、事件總數、已 結案數、未結案數、未結案比例，未結案比例四捨五入計算至小數點 後第2 位，依事件總數由高至低排序。（5 分） 查詢每位稽核人員於2026 年的處理績效，列出稽核人員姓名、所屬部 門、處理事件總數、其中高嚴重程度事件數，只列出處理事件總數大 於5 件的稽核人員，依處理事件總數由高至低排序。（5 分） 假設現新增一筆稽核政策資料，政策編號為「P2025001」，政策名稱為 「財務資料表異動稽核」，物件名稱為「Finance」，物件類型為 「TABLE」，稽核動作為「DELETE」，是否啟用為「Y」，建立者編號 為「U001」。請寫出對應的SQL 新增語法。（5 分）

參考解答（AI 生成，非官方）

  • 一、實體（Entity）與屬性辨識：本綱目可萃取出四個獨立實體。稽核政策（Audit Policy）以政策編號為候選鍵，屬性為政策名稱、物件名稱、物件類型、稽核動作、是否啟用、建立者編號；稽核日誌（Audit Log）以日誌編號為主鍵，屬性為操作時間、操作類型；異常事件（Incident）以事件編號為主鍵，屬性為嚴重程度、偵測時間、事件描述、是否已結案；稽核人員（Auditor）以稽核人員編號為主鍵，屬性為姓名、所屬部門。事件處理紀錄因帶有處理日期等描述性屬性，宜視為「處理」關聯的關聯實體（associative entity），繪圖時可畫成菱形加屬性，或畫成弱實體（weak entity）。
  • 二、關聯型態與基數標註：（1）稽核政策－稽核日誌為 1:N 的「產生（Generate）」關聯，政策端標 1、日誌端標 N（烏鴉腳），且日誌對政策為完全參與（total participation，雙線）；（2）稽核日誌－異常事件為 1:N 的「觸發（Trigger）」關聯，一筆日誌可觸發多筆異常，異常事件必屬某筆日誌；（3）稽核人員－異常事件為 M:N 的「處理（Handle）」關聯，以事件處理紀錄為橋接表，屬性含處理編號與處理日期。因處理編號為單一主鍵，允許同一人重複處理同一事件，屬多重值關聯，需在圖上以基數 (0,N) 標明。
  • 三、繪圖配置提醒：以矩形表示實體、菱形表示關聯、橢圓表示屬性，主鍵屬性加底線；1:N 關聯在 N 端畫烏鴉腳，並在連線上標示 1 與 N；參與限制以雙線表示完全參與、單線表示部分參與。另建議以虛線框或註記標明「物件類型 ∈ {TABLE, VIEW, STORE PROCEDURE, FUNCTION}」、「稽核動作 ∈ {SELECT, INSERT, UPDATE, DELETE}」、「嚴重程度 ∈ {高, 中, 低}」、「是否已結案 ∈ {Y, N}」等值域限制（domain constraint），並註明外鍵所在端。考生請依上述結構自行繪製，並確認 FK 與 PK 對應無誤。
  • 四、嚴重程度統計查詢（對應第小題）：以嚴重程度分組，用 CASE WHEN 配合 SUM 計算已結案與未結案數，再以 ROUND(...,2) 四捨五入至小數第二位。 SELECT 嚴重程度, COUNT(*) AS 事件總數, SUM(CASE WHEN 是否已結案='Y' THEN 1 ELSE 0 END) AS 已結案數, SUM(CASE WHEN 是否已結案='N' THEN 1 ELSE 0 END) AS 未結案數, ROUND(SUM(CASE WHEN 是否已結案='N' THEN 1 ELSE 0 END)*100.0/COUNT(*), 2) AS 未結案比例 FROM 異常事件 GROUP BY 嚴重程度 ORDER BY COUNT(*) DESC; 若「比例」採 0 至 1 的比率而非百分比，則去掉乘 100，結果如 0.33；答題時宜註明所採定義。
  • 五、2026 年稽核人員處理績效查詢：以稽核人員為主體串接事件處理紀錄與異常事件，日期建議採半開區間以免漏掉含時分秒的資料；「處理事件總數」宜用 COUNT(DISTINCT 事件編號)，避免同一事件多次處理被重複計數。 SELECT A.姓名, A.所屬部門, COUNT(DISTINCT H.事件編號) AS 處理事件總數, COUNT(DISTINCT CASE WHEN E.嚴重程度='高' THEN H.事件編號 END) AS 高嚴重事件數 FROM 稽核人員 A JOIN 事件處理紀錄 H ON A.稽核人員編號 = H.稽核人員編號 JOIN 異常事件 E ON H.事件編號 = E.事件編號 WHERE H.處理日期 >= '2026-01-01' AND H.處理日期 < '2027-01-01' GROUP BY A.稽核人員編號, A.姓名, A.所屬部門 HAVING COUNT(DISTINCT H.事件編號) > 5 ORDER BY 處理事件總數 DESC;
  • 六、新增稽核政策：應明列欄位名稱，避免因欄位順序或日後擴充欄位導致錯誤；字串值以單引號括住，且須符合物件類型與稽核動作的值域限制。 INSERT INTO 稽核政策 (政策編號, 政策名稱, 物件名稱, 物件類型, 稽核動作, 是否啟用, 建立者編號) VALUES ('P2025001', '財務資料表異動稽核', 'Finance', 'TABLE', 'DELETE', 'Y', 'U001'); 補充：若資料庫已建立 FK，寫入前須確認建立者編號存在於人員表；若採嚴格模式，物件類型與稽核動作可再加 CHECK 條件以確保資料完整性。

第2題

某機構資料庫有以下兩張E 與C 資料表，並存在其關聯： E(SID, CID, Grade)：共60000 筆資料，每個區塊（Block）存50 筆資料。 C(CID, Name, Credit)：共600 筆資料，每個區塊（Block）存30 筆資料。 假設該機構系統可用的緩衝區（Buffer）M 共22 頁，並執行下面SQL 語 法： SELECT E.SID, C.Name, E.Grade FROM E JOIN C ON E.CID = C.CID 目前已知關聯式資料庫中，常見的Join 演算法有三種，即Simple Nested Loop Join (SNLJ)、Block Nested Loop Join (BNLJ)與Hash Join，其I/O 成 本分別計算如下： Join 演算法 I/O 成本公式 說明 SNLJ B(R) + |R| × B(S) 對R 每一筆Tuple，掃描整個S BNLJ B(R) + ⌈B(R)/(M-2)⌉× B(S) 以Block 為單位分批載入R，每批掃描一次S；M-2 頁給外層，1 頁給內層，1 頁給輸出 Hash Join 3 × (B(R) + B(S)) 分割階段讀寫各一次，探測階段再讀一次 演算法內符號說明如下：B(R)代表資料表R 的區塊（Block）數，也就是 以R 作為JOIN 運算的驅動表（Driving Table / Outer Table）；|R|代表資料 表R 的資料筆數；M 代表可用緩衝區（Buffer）頁數；S 為要計算的資料 表。 請回答下面問題，並計算下列各演算法的I/O 成本（需列計算過程）： 使用SNLJ 法，以資料表E 為驅動表。（5 分） 使用BNLJ 法，以資料表C 為驅動表。（5 分） 使用Hash Join 法（假設分割後各Partition 可完整放入記憶體）。（5 分） 綜合比較上述三種結果，在本題情境下應選擇那種演算法？說明原 因。（10 分）

參考解答（AI 生成，非官方）

  • 一、基本參數推算：區塊數 B(R) = 資料筆數 ÷ 每區塊筆數（向上取整）。B(E) = 60000 ÷ 50 = 1200 個區塊；B(C) = 600 ÷ 30 = 20 個區塊；|E| = 60000 筆、|C| = 600 筆；緩衝區 M = 22 頁，故外層可用頁數 M − 2 = 20 頁（1 頁給內層、1 頁給輸出）。以下 I/O 成本均以「頁（page/block）讀取次數」為單位，暫不計入結果寫出與索引成本。
  • 二、SNLJ（以 E 為驅動表）：公式為 B(R) + |R| × B(S)，其中 R = E、S = C。成本 = B(E) + |E| × B(C) = 1200 + 60000 × 20 = 1200 + 1,200,000 = 1,201,200 次 I/O。此法的特性是對外層每一筆 tuple 都重新掃描整個內層表，因此成本與「外層筆數 × 內層區塊數」成正比，在大型資料表上極不經濟。
  • 三、BNLJ（以 C 為驅動表）：公式為 B(C) + ⌈B(C)/(M−2)⌉ × B(E)。因 B(C) = 20，M − 2 = 20，故 ⌈20/20⌉ = 1，代表 C 的全部 20 個區塊可一次載入記憶體，內層 E 只需掃描一次。成本 = 20 + 1 × 1200 = 1,220 次 I/O。對照若改以 E 為驅動表，則 ⌈1200/20⌉ = 60，成本為 1200 + 60 × 20 = 2,400，明顯較差，可見小表當外層較有利。
  • 四、Hash Join：公式為 3 × (B(R) + B(S))，即分割階段讀一次、寫一次，探測階段再讀一次。成本 = 3 × (1200 + 20) = 3 × 1220 = 3,660 次 I/O。此公式為簡化上限，隱含「分割後各 partition 可完整放入記憶體」的前提；若建置端（build side）整表可放入記憶體，實務上可採記憶體內雜湊表，成本可降至約 B(E) + B(C) = 1,220 次。
  • 五、綜合比較與選擇：三者成本為 SNLJ 1,201,200、BNLJ 1,220、Hash Join 3,660（依題目公式），故應選擇「以 C 為驅動表的 BNLJ」。理由：（1）C 僅 20 個區塊，恰可完全放入 M − 2 = 20 頁的外層緩衝，內層 E 僅需完整掃描一次，達到理論下限；（2）SNLJ 因逐筆重掃內層，成本高出約千倍，不可採；（3）Hash Join 公式的 3 次讀寫在小表情境下反而較貴，且需額外記憶體與雜湊建置成本。惟若放寬假設、允許 build side 常駐記憶體，Hash Join 可與 BNLJ 相當（約 1,220），此時可再比較 CPU 與記憶體成本。

第3題

假設資料庫中有三個資料項（Data Items）：A、B、C，其三者初始值皆為 100，當有三筆交易T1、T2 與T3 同時進入系統，各自交易的預期操作順 序如下所示： T1：read(A) →write(A) →read(B) →write(B) T2：read(B) →write(B) →read(C) →write(C) T3：read(C) →read(A) →write(A) 假設排程器（Scheduler）採用嚴格兩階段鎖定協定（Strict 2PL）：也就是 「在增長階段（Growing Phase），交易可以取得鎖定，但不能釋放任何鎖 定」以及「在收縮階段（Shrinking Phase），交易持有的所有互斥鎖X(X- lock)必須持續保留，直到交易提交（Commit）或中斷（Abort）後才能一 次釋放」。所有操作皆遵循著「具備鎖定升級：即若交易已持有共享鎖S， 在執行write 前必須升級為互斥鎖X」。考慮排程器依照時間序列t1 至t9 收到下列操作請求： 時間 分配請求與操作 時間 分配請求與操作 t1： T1 請求read(A) t6： T1 請求read(B) t2： T2 請求read(B) t7： T2 請求read(C) t3： T3 請求read(C) t8： T3 請求read(A) t4： T1 請求write(A) t9： T1 試圖提交(commit) t5： T2 請求write(B) 請回答以下問題： 詳細分析從t1 至t9 的執行過程中，各個交易的鎖定狀態變化，並且標 記該時間點交易是否會進入阻塞（Blocked/Waiting）狀態？（書寫時， 若某個資料項要使用S 鎖請標註Lock-S(資料項)，若需要X 鎖則書寫 Lock-X(資料項)。）（10 分） 此排程於t9 之後的時間，是否有機會形成死結（Deadlock）？若有， 請指出是那些交易互相等待。（10 分） 若排程能順利執行或經由處理後結束，請說明各交易的鎖定點（Lock Point）分別位於那一個時間點。（5 分）

參考解答（AI 生成，非官方）

  • 一、前提與規則整理：採 Strict 2PL，交易在增長階段只能取得鎖、不得釋放；進入收縮階段後，所有 X 鎖須保留至 commit 或 abort 才一次釋放。讀取需 Lock-S(資料項)，寫入需 Lock-X(資料項)；若已持 S 鎖，write 前須升級（upgrade）為 X 鎖，升級成功條件為無其他交易持有該資料項的 S 或 X 鎖。S 與 S 相容，S 與 X、X 與 X 互斥。
  • 二、t1 至 t5 的鎖定狀態：（1）t1 T1 請求 read(A)：取得 Lock-S(A)，成功，T1 持有 S(A)。（2）t2 T2 請求 read(B)：取得 Lock-S(B)，成功，T2 持有 S(B)。（3）t3 T3 請求 read(C)：取得 Lock-S(C)，成功，T3 持有 S(C)。（4）t4 T1 請求 write(A)：需將 S(A) 升級為 Lock-X(A)，因僅 T1 持有 A，升級成功，T1 持有 X(A)。（5）t5 T2 請求 write(B)：將 S(B) 升級為 Lock-X(B)，因僅 T2 持有 B，升級成功，T2 持有 X(B)。此階段尚無任何交易進入阻塞。
  • 三、t6 至 t9 的鎖定狀態與阻塞：（1）t6 T1 請求 read(B)：需 Lock-S(B)，但 B 已被 T2 以 X 鎖獨占，違反相容性，T1 進入 Blocked/Waiting，排入 B 的等待佇列。（2）t7 T2 請求 read(C)：需 Lock-S(C)，C 目前僅由 T3 持有 S 鎖，S 與 S 相容，故 T2 取得 Lock-S(C)，成功；T2 現持有 X(B) 與 S(C)。（3）t8 T3 請求 read(A)：需 Lock-S(A)，但 A 已被 T1 以 X 鎖持有，衝突，T3 進入 Blocked。（4）t9 T1 試圖 commit：T1 尚未完成 read(B) 與 write(B)，仍卡在 t6 的等待，且 Strict 2PL 下不得提前釋放 X(A)，故 commit 無法執行，T1 持續阻塞。
  • 四、死結判定：t9 之後會形成死結。等待圖（wait-for graph）為 T1 → T2（T1 等 T2 釋放 B 的 X 鎖）、T2 → T3（T2 後續 write(C) 需將 S(C) 升級為 X(C)，但 T3 持有 S(C)）、T3 → T1（T3 等 T1 釋放 A 的 X 鎖），形成 T1 → T2 → T3 → T1 的循環等待，故為死結。處理方式包含：逾時偵測（timeout）、等待圖偵測後選一犧牲者（victim）abort，或採 wait-die / wound-wait 等預防法；亦可調整封鎖粒度或先以 lock ordering 讓交易依固定順序取鎖。
  • 五、鎖定點（Lock Point）說明：鎖定點指交易取得「最後一把鎖」的時刻，亦即增長階段結束、進入收縮階段之點。原排程因死結，三筆交易皆未達鎖定點。經處理後之情境：（1）若 abort T3，T3 無鎖定點；T3 釋放 S(C) 後，T2 的 write(C) 升級 X(C) 成功，T2 鎖定點落於該升級時點；T2 commit 釋放 B 後，T1 取得 S(B) 並隨即升級 X(B)，T1 鎖定點落於 X(B) 取得時點。（2）若 abort T1，T1 無鎖定點；T3 取得 S(A) 之時為 T3 鎖定點，T3 commit 釋放 C 後，T2 升級 X(C) 成功之時為 T2 鎖定點。答題時應明確指出鎖定點隨犧牲者選擇而異。

第4題

BASE 原則（BASE Properties）與CAP 定理（CAP Theorem）常見於在 分散式系統（Distributed Systems）與分散式資料庫的架構設計中，請回 答以下問題： 解釋BASE 原則。（10 分） 解釋CAP 定理。（10 分） 在分散式資料庫中，CAP 是一項限制，為何一個分散式資料庫不可能 同時滿足CAP？（5 分）

參考解答（AI 生成，非官方）

  • 一、BASE 原則的定義與背景：BASE 由 Basically Available、Soft state、Eventually consistent 三字首組成，約於 2008 年由 Pritchett 提出，用以描述大規模網際網路服務在可用性與延遲優先於強一致時的設計取向，可視為對傳統 ACID（Atomicity、Consistency、Isolation、Durability）的反思與互補，而非全面取代。
  • 二、BASE 三要素內涵：（1）Basically Available（基本可用）：系統允許在故障或流量尖峰時降級服務，例如部分功能暫停、回應延遲增加或回傳舊資料，但仍維持整體可用。（2）Soft state（軟狀態）：狀態可能隨時間與副本同步而改變，不保證每次讀取都得到最新值，系統不強制即時收斂。（3）Eventually consistent（最終一致）：若無新的更新，經過一段時間後所有副本終將收斂至相同值。
  • 三、BASE 的實務對照與限制：採 BASE 的系統如 Amazon DynamoDB、Apache Cassandra、Riak 等，常以 quorum（讀寫門檻）、版本向量（version vector）與衝突解決（last-write-wins 或應用層合併）實現；DNS、電子郵件亦屬典型最終一致案例。其優點是高可用、低延遲、可水平擴充；限制是應用須自行處理暫時不一致、重複資料與衝突補償（如以 Saga 模式取代分散式交易）。
  • 四、CAP 定理的定義與三要素：CAP 由 Brewer 於 2000 年提出、2002 年由 Gilbert 與 Lynch 形式化證明。C（Consistency，一致性）指線性一致性，即任何讀取都回應最近一次成功寫入的結果；A（Availability，可用性）指每個到達非故障節點的請求都能在有限時間內得到非錯誤回應；P（Partition tolerance，分割容忍）指網路節點間訊息遺失或延遲時，系統仍能繼續運作。
  • 五、為何不可能同時滿足 CAP 及取捨策略：當網路發生分割（partition）時，同一份資料的兩個副本無法互通；此時若仍要求強一致，就必須拒絕或阻擋部分讀寫（犧牲 A）；若堅持每個請求都回應，兩側可能各自接受更新而造成分歧（犧牲 C）。由於分散式系統無法排除網路分割，P 實為前提而非可選項，故實務上只能在 CP 與 AP 間取捨：CP 系統如 HBase、ZooKeeper、MongoDB（多數派讀寫）；AP 系統如 Cassandra、DynamoDB、Riak。CA 僅存在於單節點或非分散式環境。另可補充 PACELC：無分割時仍須在延遲（Latency）與一致性（Consistency）間取捨。