107 外交特考四等 外交行政人員資訊組 系統分析及設計與資料庫應用概要 考古題詳解

核心觀念

本題評量概念資料庫設計（Conceptual Database Design）​中處理大型複雜系統的抽象化與視覺化技術：

1. 實體關聯模型之尺度挑戰（Scalability of ERD）：在企業級大型資料庫中，實體與關聯常多達數百個，若全數繪製於同一張圖上，會形成過度複雜、難以閱讀的「蜘蛛網圖（Spaghetti ERD）」。
2. 實體叢集（Entity Cluster）之定義：實體叢集是一種高階抽象化（High-level Abstraction）單元。它將一組彼此高度相關的實體（Entities）及其內部關聯（Relationships）包裝、合併為一個單一的「虛擬實體」（Virtual Entity / Composite Entity），藉此代表特定業務領域或子系統。
3. 階層化抽象概念：類似軟體工程的封裝（Encapsulation）或資料流程圖（DFD）的分層（Leveling），實體叢集本身也可以包含其他較小的實體叢集，形成巢狀的層級結構。

解題方法

本題為標準的申論型名詞解釋與觀念說明題，作答切入點應採「定義 $\rightarrow$ 形成原則 $\rightarrow$ 主要功用」之邏輯推進：

1. 界定定義與本質：指出實體叢集並非實體資料庫實體層（Physical Layer）的儲存結構，而是概念設計階段的塑模工具，目的是提升模型的層次感。
2. 闡明形成機制（如何組成）：

• 將強實體與其所屬之弱實體（Weak Entity）封裝。
• 將超類別／子類別（Supertype / Subtype）繼承結構整合成單一叢集。
• 將多對多（$M:N$）關聯所產生的關聯實體（Associative Entity）與相鄰實體打包。

3. 分點論述主要功用：從降低認知負荷、支援多層次檢視（Zoom-in/Zoom-out）、促進跨部門溝通、輔助專案模組化分工四個維度條列陳述。

選項分析

本題為申論問答題，無選項分析。

解題技巧

1. 防雷與名詞辨析（極重要陷阱）：

• 絕對不可將「實體叢集（Entity Cluster）」與實體儲存層的「叢集索引（Clustered Index）」或系統架構層的「資料庫叢集（Database Cluster / High Availability Cluster）」混淆。本題是在「設計資料庫（概念模型階段）」的脈絡下命題，專指 ER 模型的抽象化群組。

2. 善用軟工類比深化深度：

核心觀念 本題測驗資料庫邏輯設計（Logical Database Design）階段中「視界整合／關聯表合併（View Integration / Merging Relations）」的核心問題與處理解決技巧。 在關聯式資料庫設計中，當不同使用者視界（Views）或子系統的局部綱要（Local Schemas）整合成全域概念綱要（Global Conceptual Schema）時，常因命名慣例不一、資料語意分歧、屬性相依性改變或繼承結構隱含，導致關聯表在合併時產生語意衝突與結構異常。主要涉及的理論基礎包括：資料庫綱要整合（Schema Integration）、資料字典（Data Dictionary）、函數相依（Functional Dependency, FD）、正規化理論（Normalization: 1NF 至 3NF/BCNF）以及延伸實體關聯模型（EERD）之超型態／子型態（Supertype/Subtype）塑模。

解題方法 本題為標準申論題。解題切入點應奠基於經典資料庫系統工程（如 Hoffer 之資料庫邏輯設計理論），將關聯表合併時常發生的四種問題歸納為：「同義詞」、「同名異義詞」、「過渡相依（破壞 3NF）」與「隱含的超型態／子型態關係」。 回答架構針對每一問題依序闡述：

1. 問題定義與成因：說明結構或語意上的衝突本質。
2. 具體實例：以精簡的關聯表結構佐證問題發生情境。
3. 解決技巧：說明實務上採用的標準化、正規化或資料塑模技術。

選項分析 本題為申論題，無選項分析。

解題技巧

1. 名詞精準度：切忌使用「欄位重複」、「主鍵衝突」等口語化或模糊字眼，應使用資料庫標準專業術語：同義詞（Synonyms）、同名異義詞（Homonyms）、過渡相依（Transitive Dependencies）、超型態／子型態（Supertype/Subtype）。
2. 答題架構化：採用「問題名稱 $\rightarrow$ 定義說明 $\rightarrow$ 實例 $\rightarrow$ 解決技巧」之四段式對稱排版，能讓閱卷委員迅速掌握得分關鍵。
3. 記憶口訣：「同、異、倚、型」（同義詞、同名異義、過渡相依、超/子型態），涵蓋命名衝突（同、異）、正規化結構衝突（倚）與階層抽象衝突（型）。

【答案】

在關聯式資料庫邏輯設計階段，將多個關聯表（Relations/Tables）進行合併（View Integration）時，常發生的四種問題及其解決技巧說明如下：

一、同義詞問題（Synonyms）

• 問題說明：兩個或多個關聯表中使用不同名稱的屬性，但在現實世界中卻代表相同語意的資料項目。若直接合併，將導致同一資料重複儲存在不同欄位，造成資料冗餘與更新異常。
• 實例：學生事務系統的表格使用 StudentID 作為主鍵，而圖書館借閱系統的表格使用 Matriculation_No（學號），兩者實為同一屬性。
• 解決技巧：

1. 建立組織標準的資料字典（Data Dictionary），協調並統一屬性命名標準。
2. 選定單一具代表性的屬性名稱（如 StudentID）作為標準欄位名稱。
3. 若舊系統需要相容性，可在資料庫定義層建立別名（Alias）​或透過視界（View）進行映射支援。

二、同名異義詞問題（Homonyms）

• 問題說明：兩個或多個關聯表中使用相同名稱的屬性，但在各自的應用環境中代表完全不同的實體概念或資料語意。

核心觀念

本題考查結構化系統設計（Structured Design）中評估模組獨立性（Module Independence）​的兩大核心指標：

1. 耦合力（Coupling）：衡量不同模組之間的相依與關聯程度，為「模組間」的外部度量指標。
2. 內聚力（Cohesion）：衡量單一模組內部各組成元素（指令、資料、處理步驟）彼此關聯的緊密程度，為「模組內」的內部度量指標。
3. 優良設計通則：系統架構追求​「高內聚、低耦合」（High Cohesion, Low Coupling），以達到提高模組獨立性、降低漣漪效應（Ripple Effect）、增強程式可重用性（Reusability）與易維護性（Maintainability）的目標。

解題方法

本題為標準的申論型問答題，答題架構應採「對稱式雙主軸」呈現：

1. 界定評估功用：分別說明兩者在評估模組時的側重點（模組間互動成本 vs. 模組職責聚焦度），並指出設計目標（追求低耦合、高內聚）。
2. 層級光譜分類：依強弱／優劣順序（由佳至差或由差至佳）完整列出內聚力 7 大類型與耦合力 6 大（或 7 大）類型，並對每種類型給出簡明定義與實例，展現結構化分析的專業度。

重點類型深入剖析

一、耦合力（Coupling）之類型剖析（由最佳／最低依序至最差／最高）

1. 無耦合（No Coupling）：模組間完全獨立，無任何資料傳遞或互動。在實務系統中極少見。
2. 資料耦合（Data Coupling）【最佳】：模組間僅透過參數列傳遞非結構化的單一純資料項（如整數、字串）。模組間依賴性最低、最乾淨。
3. 標記／印記耦合（Stamp Coupling）：模組間傳遞整個複合資料結構（如 Record、Struct、物件），但接收模組僅使用其中部分欄位，造成非必要的結構依賴。
4. 控制耦合（Control Coupling）：某模組傳遞旗標（Flag）、開關或控制碼至另一模組，直接指引或決定該模組內部的執行流程。
5. 外部耦合（External Coupling）：多個模組同時依賴外部環境定義的通訊協定、裝置介面或特定資料格式。
6. 共用／共同耦合（Common Coupling）：多個模組共同存取、讀寫同一塊全域變數（Global Data Area）或全域資料結構，牽一髮動全身。
7. 內容耦合（Content Coupling）【最差】：某模組直接存取或修改另一個模組的內部資料、程式碼，或直接跳轉進入另一模組內部（如 goto），嚴重破壞封裝性。

二、內聚力（Cohesion）之類型剖析（由最佳／最高依序至最差／最低）

1. 功能性內聚（Functional Cohesion）【最佳】：模組內所有指令與元素僅共同專注完成單一且明確定義的工作或運算（如「計算平均值」）。
2. 循序性內聚（Sequential Cohesion）：模組內包含多個處理步驟，前一個步驟的輸出資料剛好是下一個步驟的輸入資料（如流水線作業：先讀檔再驗證內容）。
3. 通訊性內聚（Communicational Cohesion）：模組內的多個處理步驟操作或存取相同的輸入資料或產生相同的輸出資料，但步驟彼此間沒有前後產出相依關係。
4. 程序性內聚（Procedural Cohesion）：模組內的多個步驟必須依照特定的演算法或先後程序執行，但步驟間不具備前項輸出即後項輸入的資料相依性。
5. 時間性內聚（Temporal Cohesion）：模組內的各項任務彼此功能無直接關聯，僅因需要在同一特定時間點被執行而被包裝在一起（如系統啟動時的初始化模組「Initialize」）。
6. 邏輯性內聚（Logical Cohesion）：模組內將邏輯相關或同一範疇的工作包裝在一起，由傳入的控制參數決定執行哪一項工作（如單一模組負責處理所有列印行為，傳入 1 印報表、傳入 2 印收據）。
7. 偶然性／巧合性內聚（Coincidental Cohesion）【最差】：模組內各元素彼此之間完全沒有任何邏輯或資料上的關聯，純粹為了拼湊程式碼或縮減行數而隨機湊合在一起。

解題技巧

1. 排序記憶口訣：

• 內聚力由高（佳）到低（差）： 「功、序、訊、程、時、邏、巧」（功能、循序、通訊、程序、時間、邏輯、巧合）。
• 耦合力由低（佳）到高（差）：

核心觀念

1. 視界（View）之定義與本質： 視界在關聯式資料庫中為一種「虛擬表格」（Virtual Table）。它本身不儲存實際的實體資料（除了物化視界 Materialized View 之外），而是在資料庫的系統目錄／資料字典（System Catalog / Data Dictionary）中儲存一段定義好的 SQL 查詢語句（如 SELECT）。當使用者對視界下達查詢時，關聯式資料庫管理系統（RDBMS）會透過「查詢修改／展開機制」（Query Modification / Expansion），將視界定義動態合併至實際對基底表格（Base Tables）的查詢執行計畫中。
2. ANSI/SPARC 三層資料庫架構： 視界對應於 ANSI/SPARC 架構中的「外部層」（External Level / External View）。它提供應用程式及終端使用者客製化的外視圖，並具備達成「邏輯資料獨立性」（Logical Data Independence）的關鍵特徵。
3. 資料安全性（Data Security）與存取控制（Access Control）： 視界能將資料進行「垂直分割」（Vertical Partitioning，過濾欄位）與「水平分割」（Horizontal Partitioning，過濾列紀錄）。搭配資料庫授權語言（DCL，如 GRANT 與 REVOKE），能落實最小權限原則（Principle of Least Privilege）。

解題方法

本題為標準的資料庫系統申論題，配分通常佔 20～25 分。作答時切忌通篇文字堆疊，應切入為兩大主軸，並以條列化、架構化的方式論述：

1. 主要優點論述：依序從「查詢簡化」、「邏輯資料獨立性」、「客製化展示」、「儲存與維護效率」四個維度展開，展現對資料庫核心原理的全面掌握。
2. 達成安全性之機制論述：不應只抽象說明「可以隱藏資料」，必須明確寫出「水平限制（列過濾）」、「垂直限制（欄位過濾）」、「限制計算／統計數據」、「搭配授權機制（DCL）」以及「更新驗證（WITH CHECK OPTION）」的具體手法，並輔以精簡之 SQL 語法實例佐證。

選項分析

本題為申論／簡答題，並無選擇題選項。答題核心在於申論架構的完整性與專有名詞的精準度，評分構面及標準如下：

1. 「主要優點」構面：

• 必須明確點出「邏輯資料獨立性（Logical Data Independence）」與「簡化複雜查詢（封裝 JOIN 與子查詢）」，此為得分基準線。
• 補強「虛擬表格不額外佔用實體磁碟空間」及「統一商業邏輯」，可獲完整分數。

2. 「實施資料安全性」構面：

• 必須清楚區分「欄位層級（垂直）」與「資料列層級（水平）」的存取限制。
• 必須強調視界「必須結合權限撤銷與指派（REVOKE / GRANT）」才能真正形成安全防線；若使用者仍保有對底層基底表格的直接存取權，視界的安全機制將失去意義。

解題技巧

1. 申論結構黃金公式： 「定義名詞 $\rightarrow$ 核心優點列舉 $\rightarrow$ 安全性機制作法 $\rightarrow$ 精簡 SQL 範例」。有定義、有機制、有語法示範，能讓閱卷委員一眼看見專業度。
2. 避免常見盲點：

• 盲點一：誤以為視界會複製一份資料到磁碟中（除了 Materialized View 之外，標準 View 僅佔用定義 metadata 的空間）。
• 盲點二：誤以為只要 CREATE VIEW 就自然達成安全性。必須寫出「撤銷（REVOKE）基底表格存取權、僅授予（GRANT）視界存取權」的關鍵步驟。

3. 加分關鍵字： 答題時帶入專有名詞：「外視圖（External View）」、「邏輯資料獨立性（Logical Data Independence）」、「最小權限原則（Principle of Least Privilege）」、「WITH CHECK OPTION」。

【答案】

一、使用 SQL 產生視界（View）的主要優點

核心觀念

反正規化（de-normalization）是為了改善資料庫效能，刻意在原本已正規化的資料結構中加入冗餘資料，或合併資料表，以減少查詢時所需的連接（JOIN）與運算。其主要目的在於提升資料查詢速度。

代價是資料重複後，新增、修改或刪除資料時較容易產生不一致，因此必須額外維護資料完整性。

解題方法

先辨認題目問的是反正規化的「目的」。正規化通常著重於減少冗餘、避免更新異常並維持資料一致性；反正規化則是為了查詢效能，刻意增加一定程度的冗餘或降低正規化程度。因此選擇描述查詢效能提升的選項。

選項分析

核心觀念

正規化（normalization）是依據資料間的相依關係，將關聯拆分成較合適的結構，以減少資料重複，並降低插入、更新及刪除異常。常見正規化型式包括第一、第二、第三正規化型式與 BCNF；更高階的型式則有第四、第五正規化型式。

解題方法

判斷各選項是否符合正規化的目的、一般實務，以及正規化程度與查詢效率的關係。正規化可減少重複儲存所造成的更新異常；其他敘述若把實務上的常見程度、查詢速度或正規化步驟說成必然規則，就不正確。

選項分析

• (A) 正確。 正規化可將重複資料拆分至適當的關聯，降低同一資訊分散在多筆資料時，更新不完整或不一致的風險，因此避免更新異常是正規化的目的之一。
• **(B) 錯誤。

核心觀念

UPDATE 是資料操作語言（DML）指令，用來修改資料表中既有資料紀錄的欄位值。它不負責更改資料表名稱，也不會修改查詢條件。基本語法如下：

UPDATE 資料表名稱
SET 欄位名稱 = 新值
WHERE 條件式;

WHERE 用來指定要修改哪些資料列；省略 WHERE 時，資料表中所有資料列都會受到更新。

解題方法

先辨認各選項描述的操作對象：若是修改資料表結構或名稱，屬於資料定義語言（DDL）的範疇；若是修改資料列中的欄位值，則是 UPDATE 的用途。接著確認 WHERE 是否可用：它是 UPDATE 常見的條件子句，用來限制更新範圍。

選項分析

• (A) 用來變更資料表的名稱。錯誤。 UPDATE 修改的是資料表內的資料，不是資料表名稱。更改資料表名稱通常使用資料庫系統提供的 DDL 語法，例如 ALTER TABLE 的相關語法。

核心觀念

本題考查關聯式資料庫系統（RDBMS）的基礎架構與核心概念，涵蓋四大構面：

1. 實體完整性（Entity Integrity）與主鍵特性：主鍵（Primary Key）用於唯一識別關聯表（Relation）中的每一筆元組（Tuple/Record），具備「唯一性（Uniqueness）」與「非空值（NOT NULL）」限制。
2. 正規化理論（Normalization）：各級正規化的定義與消除的函數相依性（Functional Dependency）：

• 第一正規化（1NF）：屬性值須為基元值（Atomic Value），消除重複群（Repeating Groups）。
• 第二正規化（2NF）：符合 1NF，且消除非主鍵屬性對主鍵的「部分相依（Partial Dependency）」。
• 第三正規化（3NF）：符合 2NF，且消除非主鍵屬性對主鍵的「遞移相依（Transitive Dependency）」。
• 鮑思-科得正規化（BCNF）：消除所有決定項（Determinant）非候選鍵（Candidate Key）之函數相依。

3. SQL 資料定義語言（DDL, Data Definition Language）：用以定義或修改資料庫綱要（Schema）的基本指令。
4. 預存程序（Stored Procedure）模組化機制：資料庫端預先編譯的 SQL 程式區塊，支援模組化設計與巢狀呼叫（Nested Call）。

解題方法

本題為四選一的觀念除錯題，核心切入點在於精確檢驗各選項之陳述是否符合資料庫標準規範：

1. 先確認題目問的是「何者錯誤」。
2. 逐一檢視各選項的專有名詞定義，特別針對選項 (B) 所述「第一正規化」與「遞移相依」之配對關係進行辨析。
3. 確定選項 (B) 將「第三正規化」之目標誤植為「第一正規化」，故為本題錯誤之選項。

核心觀念

SQL-99 的 LIKE 用於比對字串樣式，主要萬用字元為：

• %：可比對零個或多個任意字元。
• _：可比對恰好一個任意字元。

題目要求 city 欄位的資料以「高」開頭、以「市」結尾，中間字元數不固定，因此需要用 % 表示任意長度的字元序列。

解題方法

比對樣式應由三部分組成：

1. 開頭固定為「高」。
2. 中間允許零個或多個任意字元。
3. 結尾固定為「市」。

所以樣式為 '高%市'，例如「高雄市」符合；只有「高市」也符合，因為 % 可以代表零個字元。

選項分析

核心觀念

本題考查 SQL 的全名、用途與基本語法特性。SQL 是關聯式資料庫常用的標準語言，主要包含資料定義語言（Data Definition Language, DDL）與資料操作語言（Data Manipulation Language, DML）；其查詢也可以巢狀使用，例如在 WHERE 子句中嵌入子查詢。

解題方法

先辨認 SQL 的正式全名，再判斷其他敘述是否符合 SQL 的用途及語法特性。SQL 的全名是 Structured Query Language（結構化查詢語言），不是「Sequence Query Language」。因此，選項（C）錯誤。

選項分析

• (A) 正確。 大部分關聯式資料庫管理系統（RDBMS）都支援 SQL，作為定義資料庫結構、操作資料及查詢資料的語言。
• (B) 正確。 SQL 包含 DDL 與 DML 等語言功能。

核心觀念

本題考物件導向分析中的「一般化」（Generalization）。當多個物件具有共同特徵時，可以將這些共通特徵抽取出來，歸納成一個較一般、較高層次的類別；原有類別則可視為該一般類別的子類別。

例如，汽車與機車都具有「車牌號碼」及「交通工具」等共通特徵，可將共通特徵歸納到「交通工具」這個一般類別中。

解題方法

看到「將物件之共同特徵歸類成一個類別」，應掌握「由多個具體或較特殊的類別，抽取共同點，形成較一般的類別」這個方向。這正是一般化的概念，因此選項 (D) 一般化 正確。

選項分析

核心觀念

本題旨在測驗結構化系統分析（Structured Analysis）中核心塑模工具——資料流程圖（Data Flow Diagram, DFD） 的本質特性、圖形限制，以及與其他塑模工具（如實體關聯圖 ERD、活動圖）的職責分工。

1. DFD 的核心目的與元件：

• DFD 屬於「功能塑模（Functional Modeling）」或「程序塑模（Process Modeling）」工具，主要用來塑模資料在系統中的流動、處理與儲存。
• 包含四大基本元素：處理（Process）、資料流（Data Flow）、資料儲存（Data Store）、外部實體（External Entity）。

2. DFD 的重要特性與先天限制：

• 缺乏時序與控制邏輯：DFD 是資料驅動（Data-driven），僅表示資料的轉換途徑，不具備控制流（Control Flow）。因此無法表示執行順序、條件分支（Decision）、迴圈（Loop）或並行（Concurrency）同步關係。
• 階層編號僅供識別：處理節點的編號（如 1.0、2.0、1.1 等）僅代表功能階層分解（Functional Decomposition）的層級代碼與追溯標籤，不代表執行的先後次序。
• 無法表示資料語意與基數：實體與實體間的關係及其基數比（Cardinality，如 1:1、1:N、M:N），屬於資料塑模範疇，應由實體關聯圖（Entity-Relationship Diagram, ERD）表達，DFD 不具備此功能。

解題方法

題目詢問「對於資料流程圖（DFD）的描述，何者錯誤」。解題切入點在於區分​「DFD 能表達什麼」​與​「DFD 不能表達什麼」：

• 檢驗各選項是否正確描述了 DFD 缺乏時序、控制與資料結構關聯的先天限制。
• 檢視是否有選項將屬於其他工具（如 ERD 或控制流圖）的塑模職責誤植於 DFD 上。

選項分析

• (A) 正確敘述（非本題所選）： DFD 僅描述資料的來源、去向與功能轉換，並沒有時間軸（Timeline）與同步信號的機制，因此無法展現兩個處理（Process）是否同時執行或需要相互等待同步。

核心觀念

本題考 UML 圖形的用途。合作圖（Collaboration Diagram，UML 2 後稱「通訊圖」）用來呈現物件間的互動：圖中以物件及其連結表示參與者的關係，並以訊息標示互動內容與傳遞順序。透過訊息及其順序，也能表達互動中的控制流程；物件間傳遞的訊息則可承載資料。

解題方法

先抓題幹的關鍵詞：「物件間」以及「訊息的傳遞」。這指向描述物件如何互相連結、交換訊息的互動圖，因此選合作圖。

活動圖也能描述資料流程與控制流程，但重點是活動、動作及其流程，不以物件間的訊息傳遞為核心。判斷時應以題幹整組特徵為準，而非只看到「流程」二字就選活動圖。

選項分析

核心觀念

本題考「軟體品質管理」相關標準與框架的用途。CMMI（Capability Maturity Model Integration，能力成熟度整合模式）用於評估及改善組織的軟體開發與管理流程，涵蓋品質管理、流程改善等實務，因此符合題目所問。

解題方法

先辨認各選項所屬領域，再與「軟體品質管理」比對：CMMI 聚焦軟體與系統開發流程的成熟度及改善；其餘選項分別屬於資訊安全管理、實驗室能力認證及硬體介面規格，與題意不符。

選項分析

• (A) ISO 27001：錯誤。 此標準規範資訊安全管理系統，重點在建立、實施及持續改善資訊安全管理，不是軟體品質管理標準。
• **(B) ISO 17025：錯誤。

核心觀念

本題考的是專案管理的五大過程群組。依一般專案管理教材與 PMI 的分類，五大過程為：起始、規劃、執行、監控與管制、結束。「查核」不是五大過程群組之一。

解題方法

辨認各選項是否屬於五大過程群組即可。題目問「何者不是」，因此找出不在「起始、規劃、執行、監控與管制、結束」之列的選項。

選項分析

核心觀念

本題的核心觀念為軟體測試目的與策略分類中的「迴歸測試（Regression Testing）」。

在軟體工程與維護生命週期中：

1. 迴歸錯誤（Regression Bug）：指在對軟體進行修改（如修復缺陷、增加新功能或重構程式碼）之後，導致原本運作正常的功能遭到破壞，或是先前已經被修復的錯誤又再度復發的現象（即系統品質產生「退化」或「倒退」）。
2. 迴歸測試（Regression Test）：指在軟體程式碼變更後，重新執行現有的測試案例集（Test Suites），以確保更動並未產生未預期的副作用（Side Effects），並確認已修復的臭蟲（Bug）未再次重現。

解題方法

1. 鎖定題目關鍵情境：

• 「程式碼修改後」：說明系統處於變更或維護階段。
• 「之前修正的程式臭蟲（Bug）又再次產生」：點出軟體發生了「品質退化／舊缺陷復發」的典型迴歸（Regression）現象。

2. 對應防範與驗證策略：

• 軟體工程實務上，為避免「治好這個、弄壞那個」或「舊錯重蹈覆徹」，團隊會在每次修復 Bug 時，將該 Bug 的重現測試案例加入測試資料庫；每次程式更新後重新執行這些測試，此一技巧即為迴歸測試。因此選項 (A) 為唯一正確解。

選項分析

• (A) 迴歸測試（Regression Test）：【正確】 旨在驗證程式修改後未對現有模組造成負面影響，能確保過去修復過的錯誤不會因新程式碼的加入或改動而重新出現。通常結合自動化測試與持續整合（CI/CD）流程進行。
• (B) 單元測試（Unit Test）：【錯誤】

核心觀念

本題考查資料倉儲的瀑布式與螺旋式建置方法。螺旋式採反覆循環、逐步交付的方式進行分析、設計、建置與測試，並在各階段蒐集使用者意見，再據以調整後續系統。因此，使用者意見通常能較快反映到系統設計中。

解題方法

逐項判斷敘述是否符合螺旋式的「反覆開發、逐步建置、持續回饋」特性。題目問「不是」螺旋式的特性，應選出與快速回饋、反覆修正相反的敘述。

選項分析

• (A) 系統能快速上線。 符合螺旋式逐步建置的精神。系統可先交付部分功能，再透過後續循環擴充與改善，不必等所有需求一次完成才上線。
• (B) 分析、設計、建置與測試反覆進行。 符合螺旋式特性。

核心觀念

本題考查實體關係模式中實體類別、關係與屬性的基本定義。

• 實體類別（Entity Type）：具有共同屬性的一類實體，例如「學生」或「課程」。
• 關係（Relationship）：描述實體之間的關聯，也可描述一個實體與自身的關聯。
• 弱實體（Weak Entity）：無法單靠自身屬性識別，須依賴其他實體及其識別關係才能識別；「弱」指識別上的依賴，不是屬性數量少。
• 屬性名稱：不同實體類別可以有同名屬性；名稱是否相同，不會使它們自動成為同一個屬性。

解題方法

逐一檢查選項是否符合 ER 模式的定義。尤其要分清楚「關係連結實體」與「關係連結關係」，並避免把弱實體的「弱」誤解為屬性較少。

選項分析

(A) 錯誤。 關係不一定至少連結兩個不同的實體類別。ER 模式允許遞迴關係（recursive relationship），即同一實體類別中的實體彼此形成關係，例如「員工管理員工」。此時關係只涉及一個實體類別，但不同實體實例以不同角色參與。

核心觀念

本題考資料倉儲的多維度線上分析（OLAP）操作。銷售資料可視為依「時間、地區、產品」等維度組成的多維資料立方體；「北美地區」是地區維度的範圍，「2017 年」是時間維度的範圍。

• 切片（slice）：固定一個維度的單一值，檢視其他維度形成的資料切面。
• 切塊（dice）：在多個維度上選取特定值或範圍，形成較小的子立方體。
• 向下探究（drill-down）：沿維度階層往更細的層次查看資料，例如由「年」展開至「季」或「月」。
• 轉軸（pivot）：旋轉或重新排列資料維度，以不同視角呈現相同資料。

解題方法

題目要查看「北美地區在 2017 年的銷售情況」，是在資料立方體中同時限定地區與時間兩個維度，取出符合條件的子集合。因此，依官方答案，最恰當的操作是 切塊（dice）。

選項分析

核心觀念

本題的核心考點為資料庫並行控制（Concurrency Control）中的衝突可序列性（Conflict Serializability）​與順序圖（Precedence Graph，又稱優先圖或 Serialization Graph）​的建圖規則。

1. 衝突操作（Conflicting Operations）的定義： 在排程（Schedule）中，若兩個操作滿足以下三個條件，則稱此兩操作互相衝突：

• 屬於不同的交易（Transactions）。
• 存取同一個資料項目（Data Item $X$）。
• 至少有一個操作為寫入（Write）。 因此，衝突的三種類型為：
• 讀寫衝突（Read-Write Conflict）：$read_i(X)$ 與 $write_j(X)$
• 寫讀衝突（Write-Read Conflict）：$write_i(X)$ 與 $read_j(X)$
• 寫寫衝突（Write-Write Conflict）：$write_i(X)$ 與 $write_j(X)$ 特別注意：讀讀（Read-Read）操作不具衝突性，因為多個交易同時或接續讀取相同資料並不會破壞資料一致性。

2. 順序圖（Precedence Graph）的建圖規則： 順序圖是一個有向圖（Directed Graph）$G = (V, E)$，其中節點（Vertex）集合 $V$ 為排程中的所有交易；有向邊（Edge）集合 $E$ 的建立原則為：

• 若交易 $T_i$ 執行了操作 $O_i(X)$，而在其後交易 $T_j$ 執行了操作 $O_j(X)$，且 $O_i(X)$ 與 $O_j(X)$ 構成衝突操作，則在圖中繪製一條由先執行的交易指向後執行的交易之有向邊： $T_i \to T_j$

3. 衝突可序列性定理： 若且唯若該排程的順序圖中不包含任何有向迴路（Directed Cycle，即為 DAG）​時，該排程才具備衝突可序列性。

解題方法

判定順序圖中的邊時，分為兩個檢驗步驟：

1. 判斷是否衝突：檢查兩操作存取相同項目時，是否「至少有一個是寫入操作」。若為「讀–讀」，則不具衝突，不畫邊。

核心觀念

本題考查基本二階段鎖定（Basic 2PL）與傷害－等待（Wound-wait）死結預防法。

傷害－等待依交易時間戳記決定是否等待：

• 較舊的交易請求較新交易持有的鎖：中止較新的交易，讓較舊交易繼續執行，稱為「傷害」。
• 較新的交易請求較舊交易持有的鎖：請求者等待，稱為「等待」。

時間戳記數值越小，代表交易越早；時間戳記數值越大，代表交易越晚。

解題方法

$T_1$ 的時間戳記為 $15$，$T_2$ 的時間戳記為 $10$，因此 $T_2$ 比 $T_1$ 舊。

$T_1$ 已對 $Y$ 執行 read_item(Y)，表示 $T_1$ 持有 $Y$ 的讀取鎖（shared lock）。$T_2$ 欲執行 write_item(Y)，需要取得 $Y$ 的寫入鎖（exclusive lock）。讀取鎖與寫入鎖不相容，因此必須依傷害－等待規則處理。

核心觀念

候選鍵是「最小超鍵」：一組屬性若能決定關聯式資料表中的所有屬性，便是超鍵；若再移除其中任何一個屬性，就不再能決定全部屬性，才是候選鍵。

計算時可用屬性閉包。對屬性集合 $X$，其閉包 $X^+$ 是依據功能相依反覆推導後，所有可由 $X$ 決定的屬性。

解題方法

題目給定：

先注意 $A_1$ 沒有出現在任何功能相依的右側，因此無法由其他屬性推得。任何候選鍵都必須包含 $A_1$。

接著分別檢查是否需要 $A_2$、$A_3$：

1. 包含 $A_1,A_2$：

由 $A_1A_2\rightarrow A_3A_4$，再由 $A_4\rightarrow A_5$，可得

因此 $\{A_1,A_2\}$ 是超鍵。移除 $A_1$ 或 $A_2$ 後均無法得到全部屬性，故為候選鍵。

2. 包含 $A_1,A_3$：

由 $A_3\rightarrow A_2$，可得 $A_1A_3\rightarrow A_1A_2$；再由 $A_1A_2\rightarrow A_3A_4$ 及 $A_4\rightarrow A_5$，可得

核心觀念

UML 使用案例圖（Use Case Diagram）中的參與者（Actor），是位於所建模系統範圍之外，會與系統互動的角色或外部實體。Actor 不限於人，也可以是其他系統、設備或外部服務；重點在於它和系統之間存在互動。

解題方法

先判斷描述是否符合兩個關鍵條件：Actor 必須在系統外部，並且會與系統互動。因此，凡是把 Actor 限定為人員、子系統，或系統內部物件的說法，都不符合定義。

選項分析

• (A) 錯誤。 Actor 不限於人員，也不限定為使用案例所牽涉的「所有」內部、外部人員。外部系統、設備或服務也能擔任 Actor；

核心觀念

本題測驗專案管理與時程排程的核心工具——計畫評核術（PERT, Program Evaluation and Review Technique）​與關鍵路徑法（CPM, Critical Path Method）​中關於工作時程參數與寬裕時間（Slack Time，又稱浮時 Float）​的定義。

在網路圖（Activity on Node, AON 或 Activity on Arrow, AOA）的時間計算中，每一項工作活動（Activity）皆有四個基本時間標記（均為時間點）：

1. 最早開始時間（Earliest Start Time, $ES$）：在所有前置作業完工後，該工作最早可以開始的時間點。
2. 最早完成時間（Earliest Finish Time, $EF$）：若該工作依最早開始時間動工，其最早可以完工的時間點。若作業工期（Duration）為 $t$，則： $EF = ES + t$
3. 最遲完成時間（Latest Finish Time, $LF$）：在不延誤整體專案預定完工日的前提下，該工作最晚必須完工的時間點。
4. 最遲開始時間（Latest Start Time, $LS$）：在不延誤整體專案預定完工日的前提下，該工作最晚必須開工的時間點： $LS = LF - t$

寬裕時間（Slack Time / Total Float）​是指在不延緩整個專案完工期限的前提下，某項工作可以容許延遲開工或延長作業時間的最大彈性額度（時間長度）。其標準數學定義為： $Slack = LS - ES = LF - EF$

解題方法

本題探討寬裕時間（Slack Time）的文字定義與運算式：

1. 依定義出發：寬裕時間代表工作開工或完工的「緩衝差值」，可由兩種等價方式計算：

• 最遲開始時間與最早開始時間之差：$LS - ES$
• 最遲完成時間與最早完成時間之差：$LF - EF$

2. 數學恆等推導： 因為工期 $t = EF - ES = LF - LS$，代入展開： $LF - EF = (LS + t) - (ES + t) = LS - ES$ 兩種算法所得數值必然相等。
3. 對照選項： 選項 (B) 敘述「該工作的最遲完成時間減去最早完成時間」（即 $LF - EF$），精準符合寬裕時間的數學定義。

核心觀念

本題測驗結構化系統分析中資料流程圖（Data Flow Diagram, DFD）之「平衡原則（Balancing Rule）」。

1. 階層式展開（Hierarchical Decomposition / Explosion）： DFD 採用由上而下（Top-down）的方式逐步分解複雜系統，通常由最頂層的「環境圖（Context Diagram）」展開為「第 0 層 DFD（Level-0 DFD）」，再進一步細化至「第 1 層 DFD（Level-1 DFD）」等。
2. 平衡原則（Balancing）定義： 當上層圖（父圖，Parent Diagram）中的某一個程序（Process）展開為下層圖（子圖，Child Diagram）時，流入與流出該父程序的資料流，必須與該子圖的所有邊界輸入／輸出資料流保持完全對應與一致。平衡原則旨在確保各階層之間的資料流邏輯具有連續性與一致性，避免資料在分解過程中遺漏或無端產生。

解題方法

由軟體工程與系統分析的標準定義切入：

• DFD 是描述資料在系統中流動與轉換的邏輯模型，其規範聚焦於「語意邏輯完整性」而非「圖面美工排版」。
• 判斷「平衡」一詞在 DFD 中的專門術語意涵：平衡並非幾何位置的平衡，亦非流量的物理守恆，而是指跨階層（父子圖）邊界資料流的一致性（Consistency across levels）。
• 比對選項，僅 (D) 選項準確表達「階層展開時上下層內容相互對應」的觀念。

選項分析

核心觀念

本題測驗軟體工程（Software Engineering）中軟體模組測試的分類方法。依據測試者是否需要查閱或考量程式原始碼的「內部實作與控制流程」，軟體測試技術主要分為兩大派別：

1. 黑箱測試（Black-Box Testing / 功能性測試 Functional Testing）： 將受測軟體視為一個不透明的黑色盒子，測試人員完全不探究、亦不依賴程式內部的原始碼、演算法、資料結構或邏輯路徑。測試案例的設計純粹依據「系統需求規格書」，透過給予特定的輸入（Input），比對其產生的輸出（Output）​與系統行為是否符合預期的功能（Function）。
2. 白箱測試（White-Box Testing / 結構性測試 Structural Testing / 透明箱測試）： 測試人員直接檢視程式原始碼與內部結構，依據邏輯流程圖（Control Flow Graph）、迴圈、條件判斷等設計測試案例，著重於程式碼的覆蓋率（如陳述覆蓋率 Statement Coverage、分支覆蓋率 Branch Coverage、路徑覆蓋率 Path Coverage 等）。

解題方法

由題幹敘述切入：

• 「完全不考慮程式內部的邏輯結構和內部特性」
• 「著重在考慮其輸入、輸出、功能」

根據軟體工程標準定義，僅依賴外在介面的輸入與輸出反應，不探究內部程式碼實作細節的測試手法，即為標準的「黑箱測試」，因此本題直接對應選項 (A)。

選項分析

• (A) 黑箱測試：正確。 黑箱測試將內部邏輯隱蔽，僅就規格書所定義的輸入範圍與期望輸出進行功能驗證。

核心觀念

本題測驗結構化系統分析與設計（Structured Systems Analysis and Design）中，模組化設計（Modularization）的核心評估指標——內聚力（Cohesion）。

在系統設計中，追求的設計準則是「高內聚、低耦合」（High Cohesion, Low Coupling）。內聚力衡量單一模組內部各元件、敘述或任務之間相互關聯與合作的緊密程度。

軟體工程中依強度將模組內聚力由高（最優）至低（最差）劃分為七個等級：

1. 功能內聚力（Functional Cohesion）：最強（最佳），模組僅執行單一且明確的獨立功能。
2. 順序／循序內聚力（Sequential Cohesion）：模組內部某項任務的輸出，恰為下一項任務的輸入。
3. 通訊／溝通內聚力（Communicational Cohesion）：模組內各任務操作或參考相同的輸入資料，或產生相同的輸出資料，但執行順序不重要。
4. 程序內聚力（Procedural Cohesion）：模組內各任務必須依特定控制流程或演算法順序執行，但彼此間未直接傳遞資料。
5. 時間內聚力（Temporal Cohesion）：模組內各任務因必須在同一時間點執行而被組合在一起（例如系統初始化或關機作業）。
6. 邏輯內聚力（Logical Cohesion）：模組將邏輯上性質相近的一組動作放在一起，由呼叫端傳入控制旗標決定執行哪一項動作。
7. 偶然／巧合內聚力（Coincidental Cohesion）：最弱（最差），模組內的各項任務毫無關聯，純粹隨機湊合在同一個檔案或函數中。

解題方法

題目詢問四個選項中「哪一種模組的內聚力最差」。解題切入點為將四個選項依內聚力光譜排列強弱順序：

$\text{功能內聚 (C)} > \text{順序內聚 (D)} > \text{程序內聚 (A)} > \text{邏輯內聚 (B)}$

在題目提供的四個選項中，邏輯內聚力排名倒數第二（僅優於七大層級中最低的「偶然內聚力」），故在選項給定的範圍內為內聚力最差者。

選項分析

• (A) 程序內聚力（Procedural Cohesion）—— 錯誤 模組內部各步驟必須依特定的順序執行，以完成某個流程控制（如先檢查使用者身分，再計算權限），但前一步驟的輸出不一定是下一步驟的輸入。

核心觀念

本題考查軟體專案度量（Software Metrics）​中的軟體規模估算技術（Software Size Estimation），並辨析其與「專案時程管理工具」的本質差異。

1. 軟體規模（Software Size）度量：衡量軟體系統所包含的軟體量或功能多寡。常見指標有兩大主流：

• 程式碼行數法（Lines of Code, LOC / KLOC）：直接以程式碼長度度量，容易受程式語言種類與工程師編寫風格影響。
• 功能點分析（Function Point Analysis, FPA）：由 Allan Albrecht 於 1979 年提出，從使用者需求視角出發，依據五大功能元件（外部輸入 EI、外部輸出 EO、外部查詢 EQ、內部邏輯檔案 ILF、外部介面檔案 EIF）計算未調整功能點（UFP），再依環境複雜度調整係數（TCF）得出最終功能點（FP），與所採用的程式語言無關。

2. 專案時程管理（Project Schedule Management）：旨在規劃任務先後順序、工期估算與進度追蹤，核心為「時間」而非「軟體規模大小」。

解題方法

解題切入點在於區分​「軟體規模評估技術」​與​「專案進度與時程排程技術」：

1. 審視題目關鍵字：「評估軟體規模大小」。
2. 對照各選項之主要功能領域：

• 選項 (A)、(B)、(C) 皆屬於專案管理中處理任務關係、活動工期與進度排程（Time/Schedule Management）​的工具。
• 選項 (D) 屬於軟體工程中專門用於度量軟體功能大小與複雜度（Size & Cost Estimation）​的標準技術。

3. 結論：僅有功能點分析適用於評估軟體規模大小。

選項分析

核心觀念

本題測驗關聯式資料庫正規化理論中的無損連結分解（Lossless-Join Decomposition）​判定。

1. 無損連結定義： 若將關聯式資料表 $R$ 切割（Decompose）為多個子資料表（例如 $R_1, R_2$），且透過自然連接（Natural Join, $\bowtie$）能完整還原為原始資料表 $R$（即 $R = R_1 \bowtie R_2$），不會產生多餘的錯誤資料（假資料／Spurious Tuples），則稱此切割具備「無損連結」性質。

2. 二元切割無損連結判定準則（Binary Decomposition Theorem）： 將關聯表 $R$ 切割為兩個子關聯表 $R_1, R_2$（滿足 $R_1 \cup R_2 = R$），該切割為無損連結的充分且必要條件為：兩子表的共同屬性（交集），必須至少能功能決定（Functionally Determine）其中一個子表的完整屬性。 亦即，共同屬性 $(R_1 \cap R_2)$ 必須是 $R_1$ 或 $R_2$ 的超鍵（Superkey）： $(R_1 \cap R_2) \rightarrow R_1 \quad \text{或} \quad (R_1 \cap R_2) \rightarrow R_2$ 以屬性閉包（Attribute Closure）檢驗，即滿足下列條件之一： $(R_1 \cap R_2)^+ \supseteq R_1 \quad \text{或} \quad (R_1 \cap R_2)^+ \supseteq R_2$

解題方法

給定關聯表 $R(A, B, C, D, E)$，功能相依集合 $F = \{A \rightarrow \{B, C, D, E\}, D \rightarrow E\}$。

1. 計算各屬性之屬性閉包（Attribute Closure）：

• $A^+ = \{A, B, C, D, E\}$（$A$ 為候選鍵／超鍵）
• $D^+ = \{D, E\}$
• $B^+ = \{B\}$
• $C^+ = \{C\}$
• $E^+ = \{E\}$

2. 檢驗步驟： 針對各選項的切割 $(R_1, R_2)$，依序求出共同屬性 $(R_1 \cap R_2)$，計算其閉包 $(R_1 \cap R_2)^+$，檢驗是否涵蓋 $R_1$ 或 $R_2$。

選項分析

• (A) 正確：
• 共同屬性：$R_1 \cap R_2 = \{A, B, C, D\} \cap \{D, E\} = \{D\}$。
• 計算交集閉包：$D^+ = \{D, E\}$。
• 檢驗是否為超鍵：
• $D^+ = \{D, E\} \not\supseteq R_1$（無法決定 $R_1$）。