107 國安局特考三等 資訊組(選試英文) 資料庫應用 考古題詳解

核心觀念

本題評量 NoSQL（Not Only SQL）資料庫的核心資料模型（Data Models）及其在大數據環境下的實務應用架構。關鍵知識點包含：

1. NoSQL 資料模型分類與儲存架構：文件式資料庫（Document-oriented Database）與鍵值式資料庫（Key-Value-oriented Database）在資料結構、綱要彈性（Schema Flexibility）、巢狀表示能力、查詢機制與索引策略上的本質差異。
2. 第一正規化（1NF）與多值屬性（Multivalued Attributes）之處理：題目給定之關聯式資料表中的「專長」欄位包含複合值（如「網路、資料庫」），在傳統關聯式資料庫中違反 1NF 原子性（Atomicity）要求，通常需透過反正規化或拆分為一對多關聯表處理；而在 NoSQL 架構下，則依據各資料模型之特性予以塑模（Modeling）。
3. 資料反正規化（Denormalization）與聚總（Aggregate-Oriented）思維：NoSQL 資料庫偏好以聚總為單位儲存資料，減少昂貴的表格連接（JOIN）運算，提升分散式環境下的讀寫效能與水平擴充能力（Scale-Out）。

---

解題方法

1. 子題 (一) 的切入點：採「對比結構化」分析，從五大維度（資料結構與格式、綱要彈性、查詢與索引能力、多值與巢狀結構支援度、效能與擴充特性）全面剖析文件式與鍵值式資料庫的儲存特性。
2. 子題 (二) 的切入點：針對文件式資料庫，以業界最通用的 JSON（JavaScript Object Notation）或 BSON 格式進行塑模。突顯其將「一筆紀錄視為單一獨立文件（Document）」的自我描述（Self-describing）特性，並特別展示如何利用「陣列（Array）」結構原生解決「專長」欄位的多值屬性問題，免除額外的關聯表與 JOIN 負擔。
3. 子題 (三) 的切入點：鍵值式資料庫核心為 $(\text{Key}, \text{Value})$ 對應。由於 Value 在資料庫引擎角度多視為不透明的字串或二進位物件（Opaque Bytes），實務上有兩種主要儲存方式：

• 粗粒度聚總法（Coarse-grained / Serialized Value）：以員工唯一鍵（如 emp:001）作為 Key，整筆紀錄序列化（JSON 字串或分隔字串）作為 Value。
• 細粒度屬性法（Fine-grained / Composite Key）或雜湊型別（Hash Data Structure）：將屬性拆解為複合鍵（如 emp:001:name、emp:001:skills），或使用支援雜湊結構（如 Redis Hash）的鍵值系統進行欄位級別的儲存。答題時兩者皆提，可展現專業完整度。

---

選項分析

本題為申論題，非選擇題，故無個別選項分析。三大子題之論述核心與給分關鍵如下：

• 第 (一) 小題（16 分）：佔分比重最高，需清楚定義兩種資料庫本質，切忌僅以口語帶過，應精確列舉資料格式（如 JSON、XML vs. String、Binary）、檢索介面（鍵值索引與次級屬性索引）、有無綱要限制等關鍵字。
• 第 (二) 小題（7 分）：必須寫出完整的 JSON 或類 BSON 結構範例，特別是「專長」轉換為陣列 ["網路", "資料庫"] 的呈現方式，並說明其在避免表格連接與保留結構彈性上的優勢。
• 第 (三) 小題（7 分）：需說明 Key 的命名空間設計（如 emp:001）以及 Value 的儲存型式，並明確指出鍵值資料庫無法直接針對 Value 內部欄位進行原生條件檢索（Secondary Query）之限制。

---

解題技巧

1. 名詞對比法：說明特性時，牢記「鍵值式是黑盒子（Value 是 opaque 的，只靠 Key 進出）」；「文件式是白盒子（文件內容具有半結構化層次，內部欄位皆可索引與查詢）」。
2. 代碼化呈現：遇到「試說明儲存情形」的題目，切忌純文字抽象描述，務必直接寫出結構化的 JSON 程式碼或 $(\text{Key}, \text{Value})$ 映射表，使閱卷委員一目了然。
3. 常見陷阱：

• 忘記處理多值屬性：將專長寫成單純字串 "網路、資料庫"，未展現出文件式資料庫支援陣列（Array）的原生強項。
• 忽視鍵值設計原則：在鍵值資料庫中未指明 Key 的命名規則（如缺少命名空間前綴，僅寫數字 001 可能導致與其他實體主鍵衝突）。

---

【答案】

(一) 文件式資料庫及鍵值式資料庫之資料儲存特性

1. 文件式資料庫（Document-oriented Database）之資料儲存特性

• 半結構化文件為儲存單位：資料以獨立、自我描述（Self-describing）的文件為基本儲存單位，常見格式為 JSON、BSON 或 XML。
• 彈性綱要（Schema-free / Dynamic Schema）：同一集合（Collection）中的不同文件不需要擁有完全相同的欄位與結構，能隨時動態新增或省略屬性，極適合需求快速變動之系統。
• 支援階層與巢狀結構：原生支援陣列（Array）與巢狀子文件（Embedded Sub-documents）。能將實體關聯模型中的一對多（1:N）關係內嵌於同一份文件中，減少傳統關聯式資料庫執行表格連接（JOIN）的效能損耗。
• 豐富的次級索引（Secondary Indexing）與查詢能力：資料庫引擎理解文件的內部結構，不僅能依文件主鍵（_id）查詢，亦可針對文件內部的任意欄位、巢狀物件或陣列元素建立索引並執行複雜的條件過濾、範圍查詢與聚合運算。

核心觀念

本題評量重點在於資料庫系統架構之演進歷程及其背後的系統設計權衡（Trade-offs）。考生須掌握以下關鍵定義與理論基礎：

1. 關聯模型與 ACID 特性：

• 關聯模型以二維表格（Relation/Table）與數學集合論為基礎。
• 遵循 ACID 原則（單元性 Atomicity、一致性 Consistency、隔離性 Isolation、耐受性 Durability），以保證高度資料完整性。

2. 分散式系統理論（CAP 定理與 BASE 模型）：

• CAP 定理：在分散式系統中，一致性（Consistency）、可用性（Availability）、分區容忍性（Partition Tolerance）三者不可兼得，至多僅能同時滿足兩項。
• BASE 模型：基本可用（Basically Available）、軟狀態（Soft state）、最終一致性（Eventual consistency），為 NoSQL 突破關聯式資料庫水平擴展瓶頸之核心哲學。

3. NewSQL 的技術突破：

• 透過分散式共識演算法（如 Raft、Paxos）、分散式時鐘協議（如 Google TrueTime API）與並行控制技術，打破傳統 CAP 定理在工程上的限制，達成「保留完整 ACID 與標準 SQL 介面」同時兼具「NoSQL 般透明水平擴展（Scale-out）」的能力。

---

解題方法

本題為申論題，答題策略應採​「對比架構分析法」：

1. 分段陳述、層次分明：依序針對「關聯式資料庫」、「NoSQL 資料庫」及「NewSQL 資料庫」立專節作答。
2. 特性構面標準化：各資料庫均由資料模型（Data Model/Schema）、交易保證（ACID vs. BASE）、擴展架構（Scale-up vs. Scale-out）​及查詢語言（Query Interface）​四個技術維度切入，確保論述周延。
3. 實例列舉具體精確：各列出三個具代表性、實務廣泛採用的著名產品，並於 NoSQL 註記其資料儲存類別，以展現專業廣度。
4. 統整綜效：末尾輔以綜合比較表，將零散論述結構化，有助於閱卷委員快速掌握作答精髓。

---

選項分析（題型與配分要點拆解）

本題為非選擇題（申論題），無選項可逐一檢視。考卷配分依題意拆解為六大得分要點：

1. 關聯式資料庫特性：須精準點出綱要固定（Rigid Schema）、正規化設計、嚴格 ACID 交易保證及垂直擴展（Scale-up）限制。
2. 關聯式資料庫實例（3個）：列舉產業界最經典之成熟產品（如 Oracle、MySQL、PostgreSQL）。
3. NoSQL 資料庫特性：須點出綱要彈性（Schema-free）、BASE 最終一致性、高度水平擴展（Scale-out）及針對巨量非結構化資料的儲存能力。
4. NoSQL 資料庫實例（3個）：列舉不同資料模型（文件、鍵值、寬行）之主流產品（如 MongoDB、Redis、Cassandra）。
5. NewSQL 資料庫特性：須強調其為兩者之集大成，具備分散式架構與橫向擴展能力，但依然原生支援標準 SQL 與強一致性 ACID 交易。
6. NewSQL 資料庫實例（3個）：列舉現代分散式關聯資料庫先驅（如 Google Spanner、CockroachDB、TiDB）。

---

解題技巧

1. 破除單純背名詞，點出「演進動機」：

• 關聯式 $\rightarrow$ NoSQL：為解決 Web 2.0 時代海量非結構化資料的「高寫入吞吐量」與「水平擴展彈性」，犧牲了強一致性。
• NoSQL $\rightarrow$ NewSQL：為了解決金融交易、核心業務等場景無法忍受「最終一致性」與缺乏「跨分區 ACID」的痛點，在保持水平擴展的前提下重拾關聯與 ACID。

2. 避免常見陷阱：

• 誤將分散式快取（如 Memcached）當作完整 NoSQL 資料庫系統。
• 誤將傳統關聯式資料庫的分庫分表（Sharding）工具或中介軟體直接等同於原生 NewSQL。NewSQL 是底層引擎即具備原生分散式交易與分散式排程。

3. 版面配置：條列標號必須清楚（例如：一、 (一)、 1.、 (1)），實例名稱嚴格採用標準大小寫英文字彙。

---

【答案】

一、傳統關聯式資料庫（Relational Database）

(一) 特性

1. 嚴謹的關聯模型與固定綱要（Rigid Schema）：以二維表格（Table）為基本儲存單元，欄位型態與結構於建表時即須預先定義（Schema-on-Write），並透過正規化（Normalization）消除資料重複性，維持參照完整性（Referential Integrity）。
2. 完整支援 ACID 交易保證：嚴格落實單元性、一致性、隔離性與耐受性，確保並行存取（Concurrency Control）與系統當機修復時資料之絕對正確性，特別適用於金融與帳務系統。
3. 標準化結構化查詢語言（SQL）：具備高度成熟的宣告式查詢語言，支援複雜的多表關聯（JOIN）、巢狀查詢與聚合運算。

核心觀念

磁碟陣列（Redundant Array of Independent Disks, RAID）是一項將多個實體硬碟結合為單一邏輯磁區的儲存虛擬化技術，核心目標在於平衡效能（Performance）、可靠度／容錯能力（Fault Tolerance / Reliability）​與儲存成本（Cost / Capacity）。

其運作奠基於三種基本機制：

1. 條帶化（Striping）：將連續資料切割為資料區塊（Blocks）或位元組（Bytes），循序交錯寫入不同硬碟，使多顆硬碟可同步執行 I/O 運作，大幅提升傳輸頻寬與平行讀寫能力。
2. 鏡射（Mirroring）：將相同資料完整寫入兩顆或以上的硬碟，提供最高的資料冗餘度（Redundancy）與快速容錯切換能力。
3. 同位元檢查（Parity）：利用邏輯互斥或運算（XOR，$\oplus$）或 Reed-Solomon 演算法計算同位元校驗碼。當任一硬碟損壞時，可利用其餘正常硬碟的資料與同位元進行布林代數反推重建資料： $D_{\text{lost}} = P \oplus D_1 \oplus D_2 \oplus \dots \oplus D_{k}$ 藉此以極低的硬碟容量開銷（Overhead）達成單碟或雙碟損壞的容錯保護。

在資料庫應用中，資料庫系統（DBMS）常根據資料庫檔案（Data Files）與交易日誌檔（Transaction/Redo Logs）的 I/O 特性（隨機存取 vs. 連續寫入、延遲敏感度），配置合適的 RAID 等級。

---

解題方法

本題為標準的申論型問答題。解題時切忌條列雜亂，應採用​「機制說明 $\to$ 特性剖析 $\to$ 優缺點列舉 $\to$ 結構化比較表 $\to$ 資料庫實務對應」​的結構作答：

1. 涵蓋等級：完整列舉標準 RAID 0 至 RAID 6，並納入實務主流的巢狀陣列 RAID 10（RAID 1+0）。特別指出 RAID 2、3、4 在歷史演進中因硬體架構受限而被 RAID 5 取代的關鍵原因。
2. 結構化剖析：對各等級清楚標示基本特性（分割單位與容錯方式）、最低硬碟需求、可用容量計算公式、容錯能力、優點與缺點。
3. 資料庫觀點切入：說明「寫入懲罰（Write Penalty）」對資料庫 OLTP 與 OLAP 系統的影響，突顯公職資訊組的專業深度。

---

選項分析

本題為國家考試之申論問答題，無選擇題之個別選項。答題重點在於完整評析各 RAID 等級的技術特性與優劣勢比較，剖析內容如下：

1. RAID 0（條帶化，Striping）

• 特性：資料以區塊為單位分散儲存於陣列內的所有硬碟上，各硬碟平行讀寫。無任何容錯或同位元機制。
• 最低硬碟數：$2$ 顆。
• 容量計算：若有 $N$ 顆相同容量 $C$ 的硬碟，可用容量為 $N \times C$（利用率 $100\%$）。
• 容錯能力：$0$ 顆（任一硬碟損壞，整個陣列資料即毀損）。
• 優點：讀寫輸送量（Throughput）極高，平行存取效能最佳；硬碟空間無任何額外耗損，成本效益最高。
• 缺點：完全無容錯能力；整體平均故障間隔時間（MTBF）隨硬碟數量增加而等比縮短，可靠度最低。

2. RAID 1（鏡射，Mirroring）

• 特性：資料在寫入主要硬碟時，同步完整複製一份寫入鏡射硬碟。
• 最低硬碟數：$2$ 顆。
• 容量計算：可用容量為 $C$（雙碟時，利用率 $50\%$）。
• 容錯能力：容許 $1$ 顆硬碟損壞。
• 優點：架構極為單純，容錯能力高；讀取時可平行讀取兩顆硬碟提升讀取效能；當有硬碟故障時，系統無須經過複雜運算即可無縫切換，重建（Rebuild）負擔最低。
• 缺點：儲存成本極高，容量利用率僅有 $50\%$；寫入時必須同時寫入兩顆硬碟，寫入效能受限於較慢的硬碟。

3. RAID 2（位元級條帶化與漢明碼校驗，Bit-level Striping with Hamming Code）

• 特性：資料以位元（Bit）為單位分散寫入各資料硬碟，並利用專屬的校驗硬碟群儲存漢明碼（Hamming Code）以提供單一位元除錯與更正（ECC）。
• 最低硬碟數：通常需 $3$ 顆資料碟搭配多顆校驗碟（常見為 $7$ 顆）。
• 優點：具備硬體級的單一位元偵錯與即時錯誤更正能力。
• 缺點：需多顆專用校驗碟，架構繁複且成本過高；因現代硬碟本身皆已內建硬體 ECC 扇區保護機制，RAID 2 已全面淘汰，實務上不再使用。

4. RAID 3（位元組級條帶化與專用同位元碟，Byte-level Striping with Dedicated Parity）

• 特性：資料以位元組（Byte）為單位條帶化分散儲存於各資料碟中，另設置一顆獨立的專用硬碟儲存 XOR 同位元資料。所有硬碟磁頭必須同步旋轉與定址（Spindle Synchronization）。
• 最低硬碟數：$3$ 顆。
• 容量計算：$(N-1) \times C$。
• 容錯能力：容許 $1$ 顆硬碟損壞。
• 優點：連續性大型資料讀寫輸送量極佳，適合大型循序視訊傳輸。
• 缺點：無法支援多工隨機存取（所有硬碟必須綁定同一步調）；專用同位元碟頻繁被寫入而成為嚴重的效能瓶頸，已被 RAID 5 取代。

5. RAID 4（區塊級條帶化與專用同位元碟，Block-level Striping with Dedicated Parity）

• 特性：改善 RAID 3 的缺點，改以磁碟區塊（Block）為分割單位分散於資料碟，各硬碟可獨立運作尋道，但仍將所有 XOR 同位元集中儲存於一顆專屬的同位元硬碟。
• 最低硬碟數：$3$ 顆。
• 容量計算：$(N-1) \times C$。
• 容錯能力：容許 $1$ 顆硬碟損壞。
• 優點：隨機讀取效能優於 RAID 3，適合讀取密集型系統。
• 缺點：所有資料區塊的寫入操作皆必須更新該專用同位元碟，造成該碟形成 I/O 寫入瓶頸（Parity Disk Bottleneck），實務上極少單獨使用。

6. RAID 5（區塊級條帶化與分散式同位元，Block-level Striping with Distributed Parity）

• 特性：採用區塊級條帶化，並將同位元校驗資訊（Parity）以輪替演算法平均分散至陣列內的所有硬碟中，徹底消除單一專用同位元碟的 I/O 瓶頸。
• 最低硬碟數：$3$ 顆。
• 容量計算：$(N-1) \times C$。
• 容錯能力：容許任 $1$ 顆硬碟損壞。
• 優點：兼顧成本效益與資料安全，空間利用率高（隨硬碟數增加而提升，如 5 顆時為 $80\%$）；讀取效能優異，平行度高。
• 缺點：存在顯著的寫入懲罰（Write Penalty）。進行小區塊隨機寫入時，系統必須執行「2 次讀取（讀舊資料、舊同位元）＋ 2 次寫入（寫新資料、新同位元）」共 4 次 I/O；此外，若單碟故障，陣列在降級運轉（Degraded Mode）與重建期間效能急遽下滑，且極易因第二顆硬碟發生不可修復讀取錯誤（URE）而導致陣列全毀。

7. RAID 6（區塊級條帶化與雙重分散式同位元，Block-level Striping with Dual Distributed Parity）

• 特性：採用區塊級條帶化，利用兩種不同的演算法（通常為 XOR 與 Reed-Solomon 演算法）計算雙份獨立的同位元校驗碼（$P+Q$ Parity），並分散儲存於所有硬碟。
• 最低硬碟數：$4$ 顆。
• 容量計算：$(N-2) \times C$。
• 容錯能力：容許任意 $2$ 顆硬碟同時損壞。
• 優點：可靠度遠高於 RAID 5，在大容量硬碟重建耗時甚長的環境下，大幅降低重建期間第二顆硬碟損壞造成災難性資料遺失的風險。
• 缺點：需要配置 2 顆硬碟的空間作為保護，硬碟容量開銷增加；寫入懲罰更為沉重（每次隨機寫入需執行「3 次讀取 ＋ 3 次寫入」共 6 次 I/O），控制器運算負擔重。

核心觀念

本題評量資料庫概念模型（Conceptual Data Model）向邏輯模型（Logical Data Model）之轉換與設計能力，涉及以下核心觀念：

1. 實體關係模型（Entity-Relationship Model, ER Model）：

• 實體（Entity）與屬性（Attribute）：識別強實體（Regular Entity）與弱實體（Weak Entity）、單值屬性、複合鍵（Composite Key）及主鍵（Primary Key, PK）。
• 關係基數比（Cardinality Ratio）與參與度（Participation Constraint）：界定 $1:N$（一對多）關係，以及實體是全面參與（Total Participation）或部分參與（Partial Participation）。
• 弱實體與識別關係（Identifying Relationship）：依附於強實體而存在的實體，其主鍵需結合父實體之主鍵與自身的部分鍵（Partial Key / Discriminator）。

2. 商業邏輯約束（Business Constraints）之塑模：

• 限制條件「每日最多只能供貨一次」在資料表設計中對應為替代鍵（Alternate Key）／唯一性約束（Unique Constraint），亦可在 ERD 中標註為相依約束。

3. ER 模型轉換為關聯式綱要（Relational Schema）規則：

• 強實體直接獨立建表。
• $1:N$ 關係將 $1$ 端之主鍵置入 $N$ 端作為外部鍵（Foreign Key, FK）。
• 弱實體轉換時，將擁有者實體之主鍵與弱實體之部分鍵合成為複合主鍵（Composite Primary Key）。

---

解題方法

1. 實體識別與屬性劃分：

• 供應商（Supplier）：強實體。屬性包含供應商編號（PK）、名稱、地址、聯繫人姓名、電話號碼。
• 帳單（Bill / Invoice）：強實體（亦可視為依附供應商的供貨事件）。屬性包含帳單編號（PK）、供應日期、金額、付款期限、說明。
• 付款記錄（Payment）：依附於帳單存在。由於同一筆帳單可在不同時間、以不同方式多次付款，付款記錄適合作為「弱實體」，其區別鍵為付款序號（或結合付款日期與付款方式），並包含實務不可或缺的付款金額。

2. 關係與基數比界定：

• 供應商 與 帳單（供應／開立關係）：
• 一位供應商可有多筆供貨帳單，每筆帳單僅屬於一位供應商，為 $1:N$ 關係。
• 帳單必須存在對應的供應商（帳單端為全面參與，雙線表示）。
• 限制處理：題目限定「每日最多只能供貨一次」，故對於同一供應商而言，(供應商編號, 供應日期) 必須具備唯一性。
• 帳單 與 付款記錄（支付關係）：
• 一筆帳單可有多筆付款記錄，每筆付款記錄僅對應一筆帳單，為 $1:N$ 關係。
• 付款記錄為弱實體，與帳單之間的關係為識別關係（雙線菱形），付款端為全面參與。

3. 邏輯綱要轉換（Mapping to Tables）：

• 套用關聯模型正規化轉換法則，定義主鍵（PK）、外部鍵（FK）及資料完整性約束（UNIQUE、NOT NULL）。

---

選項分析

本題為申論與系統設計實作題，無選擇題選項。評分關鍵與設計取捨要點如下：

• 「帳單」的主鍵設計：
• 方案 A（實務主流／最穩健）：獨立賦予帳單編號為 PK，並在資料表設定 UNIQUE (供應商編號, 供應日期)。此法具備高擴充性，能完全滿足「每日最多一次」之要求。
• 方案 B（複合鍵）：以 (供應商編號, 供應日期) 直接作為帳單的複合主鍵。雖然滿足題意，但若實務上發生同日退換貨或補開單據較缺乏彈性。本解法採「方案 A」，並附帶 UNIQUE 限制以達最佳規範。
• 「付款」是否設計為弱實體：
• 付款若脫離帳單則無實質意義，設計為弱實體能充分展現考生的資料庫理論素養；若設計為一般實體並給予獨立的付款編號亦可，但在關聯表上需額外維護獨立序號。

---

解題技巧與常見陷阱

1. 漏掉「每日最多供貨一次」的限制： 這是本題的核心鑑別點。很多考生在畫完 $1:N$ 關係後便忽略此條件，若未在 ERD 註記限制條件，或未在資料表設計中宣告 UNIQUE (供應商編號, 供應日期)，會被扣除關鍵分數。
2. 付款實體缺少關鍵屬性： 題目雖僅提及「記錄每次付款的日期及方式」，但帳單允許多次分期付款，若無「付款金額」將無法核算帳單是否結清。在國家考試中，補足「付款金額」屬於合理的專業性擴充。
3. 符號精確度（陳氏記號 Chen's Notation）：

• 弱實體使用雙線矩形。
• 識別關係使用雙線菱形。
• 部分鍵（Discriminator）使用虛線底線。
• 主鍵使用實線底線。
• 全面參與（Total Participation）使用雙線連接。

---

【答案】

(一) 實體關係圖（ER Diagram）

1. 概念模型結構說明

• 實體集（Entity Sets）：
• 供應商（Supplier）：一般實體。
• 屬性：<u>供應商編號</u>（PK）、供應商名稱、地址、聯繫人姓名、電話號碼。
• 帳單（Bill）：一般實體。
• 屬性：<u>帳單編號</u>（PK）、供應日期、帳單金額、付款期限、說明。