112 高普考高考三級 資訊處理 資料庫應用 考古題詳解

核心觀念

本題評量**實體關聯模型（E-R Model）轉換為關聯式資料庫綱要（Relational Database Schema）**的核心能力，涉及以下正規化與關聯設計原則：

1. 實體轉換為關聯（Entity to Relation）：將實體及其單值屬性直接對應為關聯表，實體之識別屬性即為關聯之主鍵（Primary Key, PK）。
2. 多值屬性（Multivalued Attribute）之處理：依據第一正規化（1NF）消除重複群與非不可分割值（Non-atomic values）之要求，多值屬性必須獨立拆成新關聯，新關聯之主鍵由「原實體主鍵」與「多值屬性本身」組成複合主鍵，同時原實體主鍵作為外來鍵（Foreign Key, FK）。
3. 一對多（1:N）關聯之轉換：將「1」端實體的主鍵，置入「N」端實體所對應的關聯中，作為「N」端關聯的外來鍵。
4. 多對多（M:N）關聯之轉換：必須建立獨立的關聯表（聯結表／關聯實體），以兩端實體之主鍵組成複合主鍵，兩主鍵各自為外來鍵；若關聯本身帶有屬性（Descriptive Attribute），亦納入此關聯表中。

---

解題方法

根據題幹 9 項需求逐一分析並推導關聯綱要：

步驟一：分析實體與單值／多值屬性

• 學系實體（DEPARTMENT）（需求 1）：
• 屬性包含 DeptId、DeptName。DeptId 可唯一識別學系，定為主鍵。
• 教授實體（PROFESSOR）（需求 4）：
• 屬性包含 ProfId、ProfName、ProfRank。ProfId 為主鍵。
• 學生實體（STUDENT）與電子信箱（需求 3）：
• 基本單值屬性包含 StudId、StudName。StudId 為主鍵。
• StudEmail 為多值屬性（題幹明載「有學生會有多個電子信箱」），為符合第一正規化（1NF），不可存於單一欄位中，須獨立建立 STUDENT_EMAIL 關聯。
• 課程實體（COURSE）（需求 2）：
• 屬性包含 CrsId、CrsName、CrsDescrip、CrsCredit。CrsId 為主鍵。

步驟二：處理一對多（1:N）關係與外來鍵配置

• 學系與學生（1:N）（需求 6）：
• 一個學系有多名學生，每名學生僅隸屬於一個學系。
• 將 1 端主鍵 DeptId 放至 N 端 STUDENT 關聯中作為外來鍵。
• 學系與教授（1:N）（需求 7）：
• 一個學系有多位教授，每位教授僅隸屬於一個學系。
• 將 1 端主鍵 DeptId 放至 N 端 PROFESSOR 關聯中作為外來鍵。
• 學系與課程（1:N）（需求 5）：
• 一個學系開授多門課程，每門課程僅由一個學系開授。
• 將 1 端主鍵 DeptId 放至 N 端 COURSE 關聯中作為外來鍵。
• 教授與課程（1:N）（需求 8）：
• 一位教授開授多門課程，每門課程僅由一位教授開授。
• 將 1 端主鍵 ProfId 放至 N 端 COURSE 關聯中作為外來鍵。

步驟三：處理多對多（M:N）關係與關聯屬性

• 學生與課程（M:N）（需求 9）：
• 學生可修習多門課程，課程可由多名學生修習，具修課成績 Grade。
• 建立選課關聯 STUDENT_COURSE（或稱修課紀錄 ENROLL），屬性包含 StudId、CrsId 與 Grade。
• 複合主鍵為 (StudId, CrsId)；其中 StudId 參照 STUDENT(StudId)，CrsId 參照 COURSE(CrsId)。

---

解題技巧

1. 多值屬性陷阱（極易失分點）： 需求 3 特別強調「有學生會有多個電子信箱」，在設計關聯式綱要時，若直接在 STUDENT 關聯中放置 StudEmail，會違反第一正規化（1NF）的原子性要求。必須敏銳察覺並拆出 STUDENT_EMAIL 關聯。
2. 多個 1:N 匯聚於同一關聯：

核心觀念

本題的核心在於關聯式資料庫的「正規化理論（Normalization Theory）」與「綱要分割（Schema Decomposition）準則」：

1. 第二正規化（2NF）的定義與性質：

• 定義：關聯綱要處於第一正規化（1NF），且每一個「非主屬性（Non-prime Attribute）」皆「完全功能相依（Fully Functionally Dependent）」於任何候選鍵（Candidate Key），即不存在部分功能相依（Partial Functional Dependency）。
• 定理：若關聯綱要的所有候選鍵（含主鍵）皆由**單一屬性（Single Attribute）**構成，則該關聯綱要必然符合 2NF。因為單一屬性不存在非空的真子集（Proper Subset），不可能產生部分相依。

2. 第三正規化（3NF）的定義：

• 定義：關聯綱要處於 2NF，且每一個非主屬性皆不「傳遞相依（Transitively Dependent）」於候選鍵。
• 形式化條件：對於關聯綱要中成立的任何非平庸功能相依 $X \rightarrow Y$，$X$ 必須為超鍵（Superkey），或者 $Y$ 中的每一個屬性皆為候選鍵的組成屬性（即主屬性）。

3. 綱要分割（Decomposition）的兩大理論基礎：

• 無失真連接分割（Lossless-Join Decomposition）：分割後的子關聯經由自然連接（Natural Join, $\bowtie$）運算後，能夠精確還原為原關聯的資料內容，不會產生額外的虛假資料組（Spurious Tuples）。
• 保持功能相依性（Dependency Preservation）：原關聯綱要具備的所有功能相依性，在分割後的各子關聯綱要之相依性閉包聯集下依然成立，使系統在進行新增或修改時，無須執行耗損效能的跨表連接即可驗證資料完整性。

---

解題方法

步驟一：屬性分類與功能相依集分析

• 全體屬性集合： $R = \{EmpId, EmpName, EmpBdate, EmpAddr, DeptNum, DeptName, DmgrId\}$
• 主鍵（Primary Key）： $PK = \{EmpId\}$ 由於主鍵可唯一識別 EMP-DEPT 中的每一筆員工參與部門紀錄，故唯一的候選鍵（Candidate Key）為 $\{EmpId\}$。
• 主屬性（Prime Attribute）：$\{EmpId\}$。
• 非主屬性（Non-prime Attribute）：$\{EmpName, EmpBdate, EmpAddr, DeptNum, DeptName, DmgrId\}$。
• 功能相依集合（Functional Dependencies, $F$）：

1. $FD_1: \{EmpId\} \rightarrow \{EmpName, EmpBdate, EmpAddr\}$
2. 依題意員工參與部門且 $\{EmpId\}$ 為主鍵，故有隱含相依：$\{EmpId\} \rightarrow \{DeptNum\}$
3. $FD_2: \{DeptNum\} \rightarrow \{DeptName, DmgrId\}$

步驟二：檢驗是否符合 2NF

1. 檢驗是否存在「部分功能相依」：

• 部分相依的定義為：存在非主屬性相依於候選鍵的真子集（Proper Subset）。
• 關聯綱要 EMP-DEPT 的候選鍵為單一屬性 $\{EmpId\}$，其非空真子集不存在（僅有空集合 $\emptyset$）。

2. 因此，所有非主屬性皆完全功能相依於主鍵 $\{EmpId\}$，不存在任何部分相依。
3. 結論：關聯綱要 EMP-DEPT 已經符合 2NF（無須亦無法再進行 2NF 的分割）。

步驟三：檢驗是否符合 3NF 並進行分割

1. 檢驗是否存在「傳遞功能相依」：

• 觀察功能相依鏈： $\{EmpId\} \rightarrow \{DeptNum\} \quad \text{且} \quad \{DeptNum\} \rightarrow \{DeptName, DmgrId\}$
• 在功能相依 $FD_2: \{DeptNum\} \rightarrow \{DeptName, DmgrId\}$ 中：
• 左邊決定者 $\{DeptNum\}$ 不是超鍵（無法唯一決定全體屬性）。
• 右邊被決定者 $\{DeptName, DmgrId\}$ 皆為非主屬性。
• 這構成了非主屬性對主鍵 $\{EmpId\}$ 的傳遞相依，因此 EMP-DEPT 不符合 3NF。

2. 進行 3NF 正規化分割：

• 將造成傳遞相依的決定屬性與其決定的屬性抽出建立獨立綱要，消除傳遞相依：
• 部門關聯：$DEPT(\underline{DeptNum}, DeptName, DmgrId)$，主鍵為 $\{DeptNum\}$。
• 員工關聯：$EMP(\underline{EmpId}, EmpName, EmpBdate, EmpAddr, DeptNum)$，主鍵為 $\{EmpId\}$，其中 $DeptNum$ 為參照 $DEPT$ 的外鍵（Foreign Key）。

步驟四：論述分割（Decompose）的理論基礎

將關聯綱要 EMP-DEPT 分割為 $EMP$ 與 $DEPT$ 的理論基礎包含以下兩大定理與準則：

1. 無失真連接分割（Lossless-Join Decomposition）：

核心觀念

本題評量資料庫並行控制（Concurrency Control）中的**衝突序列性（Conflict Serializability）**及其驗證圖形演算法——優先圖演算法（Precedence Graph Algorithm，又稱衝突圖 / Serialization Graph）。

1. 衝突操作（Conflicting Operations）： 在同一個行程（Schedule）中，若兩個操作 $O_i$ 與 $O_j$ 同時滿足以下三個條件，即構成衝突：

• 屬於不同的交易（Transactions）：$T_i \neq T_j$。
• 存取相同的資料項目（Same Data Item）。
• 兩個操作中**至少有一個為寫入（Write）**動作。 即包含三種類型：Read-Write、Write-Read、Write-Write。

2. 優先圖（Precedence Graph）定義： 優先圖 $G = (V, E)$ 是一個有向圖：

• 節點集合 $V$：行程中參與的所有交易 $\{T_1, T_2, \dots, T_n\}$。
• 有向邊集合 $E$：若 $T_i$ 的操作 $O_i$ 早於 $T_j$ 的操作 $O_j$ 執行，且 $O_i$ 與 $O_j$ 為衝突操作，則在圖中建立一條有向邊 $T_i \to T_j$，邊上標示其衝突之資料項目（如 $X, Y, Z$）。

3. 衝突序列性定理（Conflict Serializability Theorem）： 一個行程具衝突序列性，若且唯若其優先圖為「有向無環圖」（Directed Acyclic Graph, DAG）。

• 有迴圈（Cycle）：不具序列性（Non-serializable）。
• 無迴圈（Acyclic）：具序列性（Serializable）。

4. 對等序列行程（Equivalent Serial Schedule）求法： 若優先圖為無環圖，對該圖進行拓撲排序（Topological Sort），所得之全序即為與原行程衝突對等的序列行程。

---

解題方法

一、行程 A（Schedule A）分析

按時間順序檢視各操作，找出所有跨交易的衝突操作（依資料項目分組分析）：

1. 資料項目 $X$ 的衝突分析：

• 步驟 4：$T_1$ read(X)
• 步驟 7：$T_1$ write(X)
• 步驟 9：$T_2$ read(X)
• 步驟 12：$T_2$ write(X)
• 衝突邊：
• 步驟 4 的 $T_1$ read(X) 先於 步驟 12 的 $T_2$ write(X) $\implies T_1 \xrightarrow{X} T_2$
• 步驟 7 的 $T_1$ write(X) 先於 步驟 9 的 $T_2$ read(X) $\implies T_1 \xrightarrow{X} T_2$
• 步驟 7 的 $T_1$ write(X) 先於 步驟 12 的 $T_2$ write(X) $\implies T_1 \xrightarrow{X} T_2$
• 產生有向邊：$T_1 \xrightarrow{X} T_2$

2. 資料項目 $Y$ 的衝突分析：

• 步驟 2：$T_2$ read(Y)
• 步驟 3：$T_3$ read(Y)
• 步驟 5：$T_2$ write(Y)
• 步驟 8：$T_3$ write(Y)
• 步驟 11：$T_1$ read(Y)
• 步驟 13：$T_1$ write(Y)
• 衝突邊：
• 步驟 2 的 $T_2$ read(Y) 先於 步驟 8 的 $T_3$ write(Y) $\implies T_2 \xrightarrow{Y} T_3$
• 步驟 3 的 $T_3$ read(Y) 先於 步驟 5 的 $T_2$ write(Y) $\implies T_3 \xrightarrow{Y} T_2$
• 步驟 5 的 $T_2$ write(Y) 先於 步驟 8 的 $T_3$ write(Y) $\implies T_2 \xrightarrow{Y} T_3$
• 步驟 2/5 的 $T_2$ 操作先於 步驟 11/13 的 $T_1$ 操作 $\implies T_2 \xrightarrow{Y} T_1$
• 步驟 3/8 的 $T_3$ 操作先於 步驟 11/13 的 $T_1$ 操作 $\implies T_3 \xrightarrow{Y} T_1$
• 產生有向邊：$T_2 \xrightarrow{Y} T_3$、$T_3 \xrightarrow{Y} T_2$、$T_2 \xrightarrow{Y} T_1$、$T_3 \xrightarrow{Y} T_1$

3. 資料項目 $Z$ 的衝突分析：

• 步驟 1：$T_2$ read(Z)
• 步驟 6：$T_3$ read(Z)
• 步驟 10：$T_3$ write(Z)
• 衝突邊：
• 步驟 1 的 $T_2$ read(Z) 先於 步驟 10 的 $T_3$ write(Z) $\implies T_2 \xrightarrow{Z} T_3$
• 產生有向邊：$T_2 \xrightarrow{Z} T_3$

Schedule A 優先圖彙整：

• 節點：$\{T_1, T_2, T_3\}$
• 標記邊：
• $T_1 \xrightarrow{X} T_2$
• $T_2 \xrightarrow{Y, Z} T_3$
• $T_3 \xrightarrow{Y} T_2$
• $T_2 \xrightarrow{Y} T_1$
• $T_3 \xrightarrow{Y} T_1$

論述與結論： 優先圖中存在雙向環（Cycle）：

• $T_2 \xrightarrow{Y} T_3$ 與 $T_3 \xrightarrow{Y} T_2$，構成迴圈 $T_2 \to T_3 \to T_2$。
• 同時存在迴圈 $T_1 \xrightarrow{X} T_2 \xrightarrow{Y} T_1$。

核心觀念

本題考查**分散式資料庫系統（Distributed Database System, DDBS）**的系統架構與資料透明度特性：

1. 三層主從架構（Three-tier Client-server Architecture）：將系統切分為「表現層（Presentation Tier）」、「應用邏輯層（Application / Business Logic Tier）」與「資料庫層（Database Tier）」，著重於職責分離、集中商業邏輯、降低網路負載與提升分散式環境下的擴充彈性。
2. 分散透明度（Distribution Transparency）：分散式資料庫的核心目標是向使用者隱藏資料在實體網路上的分散細節，使使用者操作分散式資料庫如同操作單一集中式資料庫。依抽象層次主要包含分割透明度（Fragmentation Transparency）、位置透明度（Location Transparency）與複本透明度（Replication Transparency）。

---

解題方法

1. 第一部分（架構圖與運作原理）：

• 繪製清晰的階層圖，包含三層實體（客戶端、應用伺服器、分散式資料庫伺服器）與彼此間的溝通界面。
• 依「層次職責」、「資料與請求流程」以及「在分散式資料庫中的效益」三個面向論述其運作原理。

2. 第二部分（三種透明度及相關技術）：

• 挑選最關鍵的三大資料透明度（分割、位置、複本），採層次化結構（由高抽象至低抽象）說明。
• 針對每一種透明度，明確給出「定義（使用者視角）」與「實現技術（DDBMS 內部機制）」。

---

解題技巧

1. 排版版面技巧：國家考試作答時間有限，第一小題應先畫出整齊的方塊圖，圖中標記資料傳遞箭號（如 HTTP/RPC、SQL/Distributed Query），隨後條列說明各層角色，切忌純文字堆疊。
2. 透明度層次記憶法：透明度的層級由高至低為： $\text{分割透明度（最高）} \longrightarrow \text{位置透明度} \longrightarrow \text{複本透明度} \longrightarrow \text{局部資料庫層（最低）}$ 回答時點出此層次關係，能展現出兼具宏觀理論與實務架構的深厚底子。
3. 技術具體化：論述「相關技術」時務必寫出具體名詞（如全域資料目錄 DDC、查詢重組技術、兩階段提交 2PC、ROWA 協定等），避免流於泛泛空談。

---

【答案】

一、分散式資料庫系統三層主從架構圖與運作原理

(一) 三層主從架構圖

┌─────────────────────────────────────────────────────────────┐
│ 客戶端層（Client / Presentation Tier） │
│ - 使用者介面（Web Browser, GUI App, Mobile App） │
└──────────────────────────────┬──────────────────────────────┘
 │ 請求 (HTTP / RESTful API / RPC)
 │ 回應 (JSON / HTML)
┌──────────────────────────────▼──────────────────────────────┐
│ 應用伺服器層（Application / Business Logic Tier） │
│ - 商業邏輯運算、權限控管、交易協調 │
│ - 全域交易管理員（Global Transaction Manager, GTM） │
└──────────────────────┬──────────────────────┬───────────────┘
 │ │
 分散式查詢 / SQL│ │分散式查詢 / SQL
 │ │
┌──────────────────────▼───────┐ ┌───────▼──────────────┐
│ 資料庫站台 A（Database Site A）│ │ 資料庫站台 B（Database Site B）│
│ - 局部 DBMS（LDBMS） │ │ - 局部 DBMS（LDBMS） │
│ - 實體資料儲存（Site A Data）│ │ - 實體資料儲存（Site B Data）│
└──────────────────────────────┘ └──────────────────────────────┘

(二) 運作原理論述

1. 各層職責劃分：

• 第一層：客戶端層（Presentation Tier）： 負責與使用者進行互動，呈現資料與接收輸入。客戶端通常為「輕量型客戶端（Thin Client）」，內部不包含商業邏輯或直接存取資料庫的驅動程式，僅負責格式驗證與顯示輸出。
• 第二層：應用伺服器層（Application / Business Logic Tier）： 系統的核心中樞，負責執行所有的業務邏輯與規則處理。