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

核心觀念

本題考查 SQL 的集合篩選、反向條件，以及分組彙總。

• 具備技能 '001' 但不具備 '002'：先以 EXISTS 確認員工有 '001' 技能，再以 NOT EXISTS 排除也有 '002' 技能的員工。
• 計算每位員工參與專案的次數：由 Employee 連接 Participation，依員工分組，再用 COUNT 計算參與紀錄筆數。題目列出部門所有員工，因此沒有參與紀錄的員工也要保留，須使用 LEFT JOIN。

解題方法

（一）具備 '001'、不具備 '002' 的員工

SELECT e.eID, e.eName
FROM Employee AS e
WHERE EXISTS (
 SELECT 1
 FROM Qualified AS q
 WHERE q.eID = e.eID
 AND q.sID = '001'
)
AND NOT EXISTS (
 SELECT 1
 FROM Qualified AS q
 WHERE q.eID = e.eID
 AND q.sID = '002'
);

EXISTS 檢查是否至少有一筆符合條件的技能紀錄；NOT EXISTS 則確認不存在 '002' 的技能紀錄。兩個條件都以同一位員工的 eID 關聯，因此結果恰為具有 '001' 且沒有 '002' 的員工。

（二）列出 D01 部門員工及參與專案次數

核心觀念

**序列排程（Serial Schedule）**是指多個交易依序完整執行：一個交易完成後，才開始執行下一個交易；交易內各操作的先後次序不變。以 $T1$、$T2$ 為例，序列排程只有「先完整執行 $T1$ 再執行 $T2$」或「先完整執行 $T2$ 再執行 $T1$」兩種。

序列排程不會交錯執行交易，因而容易確保資料庫的一致性；但若交易必須彼此等待完成，並行度低，資源利用率與處理效能也可能較差。

**可循序列排程（Serializable Schedule）**是指操作雖然交錯執行，但其結果等價於某一個序列排程。它不要求實際執行順序是整筆交易依序完成，而要求並行執行的結果仍如同依序執行，藉此兼顧並行處理與正確性。

兩者關係是：**每一個序列排程都是可循序列排程；可循序列排程則不一定是序列排程。**前者描述實際的執行形式，後者描述執行結果與正確性。

結果等價與衝突等價

**結果等價（Result Equivalent）**著重於排程執行後的資料庫狀態是否相同。若兩個排程從相同初始狀態出發，執行後得到相同的資料庫結果，即為結果等價。判斷時通常要考量各項讀取所使用的值，以及最後寫入的值；只看最終狀態有時不足以說明交易所觀察到的資料是否相同。

**衝突等價（Conflict Equivalent）**著重於操作順序。若兩個排程包含相同的操作，且每一對屬於不同交易、作用於同一資料項的衝突操作，其先後次序都相同，便是衝突等價。

衝突操作須同時符合：

1. 操作來自不同交易。
2. 存取同一資料項。
3. 至少一個操作是寫入。

因此，$read-read$ 不衝突；$read-write$、$write-read$、$write-write$ 則衝突。衝突等價是可循序列性的充分判準之一；若排程與某個序列排程衝突等價，便可判定為衝突可循序列。

解題方法

逐一檢查 Schedule A 與 Schedule B 中跨交易、作用於相同資料項且至少有一個寫入的操作，再比較兩排程中這些衝突操作的相對先後順序。$commit$ 不讀寫資料項，不列入衝突操作比較。

Schedule A 與 Schedule B 的衝突比較

兩排程都有相同的操作：$T1$、$T2$ 各自讀寫 $x$、$y$。以下列出跨交易且衝突的操作順序。

核心觀念

本題考 EER 圖轉關聯表，重點是辨認：

• 超類型與子類型：Employee 是超類型；SalesRepresent、Engineer 是子類型。
• 重疊限制：專化圓圈中的 o 表示重疊，故同一位員工可以同時屬於兩個子類型。
• 部分專化：超類型連到專化圓圈的單線表示部分專化，因此員工也可以不屬於任何一個子類型。
• 多值屬性與弱實體：{regions}、{specialities} 是多值屬性，需各自拆表；Child 是弱實體，識別時要搭配其所依附的 Employee。
• 關係基數：work for 是部門與員工的關係；manage 是員工管理部門的關係；raise 是員工與子女的識別關係。

解題方法

先讀出各實體主鍵與屬性，再依關係基數決定外鍵放置位置。接著把複合屬性拆成原子欄位、多值屬性拆成獨立關聯表，最後把超類型與子類型分表，並用超類型主鍵同時作為子類型的主鍵與外鍵。

（一）子類型識別子

在 Employee 加入 subtypeCode，資料型態採 CHAR(1)，代碼定義如下：

此設計同時符合圖中的重疊與部分專化：B 表示重疊，N 表示部分專化允許未歸入任何子類型。應以檢查限制確保 subtypeCode 與子類型表中的資料一致，例如 B 的員工必須同時出現在兩個子類型表中。

（二）關聯表設計

以下以表名列出主鍵（PK）及外鍵（FK）。Employee.name(firstName,lastName) 依複合屬性拆為兩欄；Child 以員工鍵與子女的部分鍵 name 組成複合主鍵。

1. Department Department(dID PK, name, manager_eID FK → Employee.eID UNIQUE NOT NULL)

2. Employee Employee(eID PK, firstName, lastName, salary, subtypeCode, dID FK → Department.dID NOT NULL)

核心觀念

本題考查關聯式資料庫的 ACID 交易特性，以及 NoSQL 在分散式環境下如何處理一致性與資料完整性。ACID 分別是：

• Atomicity（原子性）：交易中的操作全部成功，或全部回復；不留下只完成一部分的狀態。
• Consistency（一致性）：交易前後，資料都符合資料庫所設定的完整性限制與規則。
• Isolation（隔離性）：並行交易的執行效果，等同於依某種序列順序執行，避免彼此產生不合法的干擾。
• Durability（持久性）：交易一旦提交，即使系統故障，已提交的結果仍可保存與恢復。

題目所稱「資料完整性」，是指資料符合預先定義的正確性與有效性規則，例如主鍵唯一、外鍵參照有效、欄位值符合型別或範圍限制，以及業務規則成立。它與「可用性」或「資料有備份」並非同一概念。

解題方法

作答時，先判斷題幹把 ACID 描述為 SQL 執行必備特性是否適用於 NoSQL，再說明 NoSQL 的設計取捨及完整性如何維護。

答案不能簡化成「NoSQL 沒有 ACID」。NoSQL 是多種資料庫系統的統稱，交易能力依產品、資料模型和操作範圍而異。有些 NoSQL 系統支援完整或部分 ACID 交易；有些則為了分散式擴充與可用性，採取較寬鬆的一致性模型，並以應用程式或其他機制維護完整性。

NoSQL 是否適用相同設計特性

NoSQL 不必然採用與傳統關聯式資料庫完全相同的 ACID 設計，也不能一概認定完全不支援 ACID。應依下列特性分別說明：

1. 原子性：有些系統只保證單筆文件、單一鍵值或單一資料分區內的操作原子；跨多筆資料或多個分區的交易則未必具備相同保證。
2. 一致性：若系統提供交易，可以在交易提交時維持所定義的約束；若採較寬鬆的一致性，複本可能暫時不同步，資料需經一段時間才收斂。這種設計不代表資料永久不一致，而是讓一致性保證與延遲、可用性等需求作取捨。