113 高普考高考二級 資訊處理 高等資料庫設計 考古題詳解

核心觀念

資料庫設計分為兩個層次：

• 邏輯資料庫設計：把需求轉換成與特定資料庫管理系統（DBMS）無關的邏輯結構，回答「要儲存哪些資料、資料彼此如何關聯、有哪些限制」。
• 實體資料庫設計：依選定的 DBMS 與實際工作負載，把邏輯結構轉換成可實際執行的儲存與存取方案，回答「資料如何儲存、如何有效存取」。

本題分別要求說明兩階段的輸入、輸出與主要考量。作答時應按照「從需求到邏輯結構，再由邏輯結構到實體結構」說明，並清楚區分資料語意與效能實作。

（一）邏輯資料庫設計

輸入

邏輯設計的主要輸入包括：

1. 概念資料模型：例如由需求分析建立的實體關係圖（ER Diagram），描述實體、屬性、關係及基數。
2. 使用者需求與業務規則：包括需要儲存的資料、資料間的關聯、允許或禁止的操作，以及資料完整性要求。
3. 資料需求與交易需求：常見查詢、更新與報表需求，可協助檢查資料模型是否能支援實際業務作業。

輸出

主要輸出為與特定 DBMS 無關或低度相關的邏輯結構規格。若採關聯式資料模型，通常包括：

• 關聯表（資料表）的名稱與欄位。
• 各表的主鍵、候選鍵及外鍵。
• 欄位的資料範圍與資料型態等邏輯定義。
• 實體完整性、參照完整性及其他業務限制。
• 正規化後的關聯結構與資料字典。

主要考量

1. 正確表達資料語意：實體、屬性與關係應能完整反映使用者需求及業務規則；多對多關係通常須轉換為關聯表。
2. 選擇適當鍵值：主鍵應能唯一識別資料列；外鍵則用來表達表與表間的參照關係。
3. 降低冗餘與更新異常：依功能相依等條件進行正規化，避免插入、修改及刪除異常；同時確認拆分後仍可透過連接還原所需資訊。
4. 定義完整性限制：明確規定欄位是否可為空、唯一性、參照完整性及其他業務限制。
5. 檢查需求涵蓋程度：確認邏輯結構能支援所需查詢與交易，不遺漏必要資料，也不保留沒有用途的資料。

（二）實體資料庫設計

輸入

實體設計的主要輸入包括：

1. 邏輯資料庫結構：已確認的資料表、欄位、鍵值、關係及完整性限制。
2. DBMS 與平台資訊：選定的資料庫管理系統、其資料型態、索引與儲存機制，以及硬體、作業環境等條件。

核心觀念

本題考查功能相依、候選鍵、資料異常與正規化。依圖中箭頭，功能相依為：

因此，$A1$ 與 $A2$ 合併可決定全部欄位，候選鍵為 $\{A1,A2\}$；$A1$、$A2$ 是主屬性，其餘欄位皆為非主屬性。

（一）資料異常

• 新增異常：會發生。 整個檔案以 $(A1,A2)$ 為鍵，若要新增與 $A1$ 或 $A2$ 相關的資料，必須同時提供另一個鍵值及其餘欄位，否則無法單獨記錄。例如，無法只新增某個 $A2$ 對應的 $A3,A4,A5$ 資料而不提供 $A1$。
• 修改異常：會發生。 同一個 $A2$ 對應的 $A3,A4,A5$，或同一個 $A6$ 對應的 $A8$ 至 $A12$，可能隨其他欄位重複出現在多筆資料中。若修改時漏改部分資料，便會產生不一致。
• 刪除異常：會發生。 刪除某筆資料時，可能連帶刪除其他仍有價值的相依資訊。例如，刪除某個 $A6$ 對應的最後一筆紀錄，也會失去該 $A6$ 所對應的 $A8$ 至 $A12$ 資料。

（二）正規化判斷與分解

第一正規化（1NF）：符合。 圖中各欄位以單一欄位表示；在各欄位值皆為原子值、沒有重複群組的前提下，符合 1NF。功能相依本身不會使關係違反 1NF。

第二正規化（2NF）：不符合。 2NF 要求先符合 1NF，且每個非主屬性都必須完全相依於每一個候選鍵，不能只相依於複合鍵的一部分。本題候選鍵是 $(A1,A2)$，但有：

核心觀念

啟動器（trigger）是資料庫中由特定事件自動觸發的程序。當資料表發生新增（INSERT）、修改（UPDATE）或刪除（DELETE）等事件時，資料庫會依設定的觸發時機與條件，自動執行預先定義的動作。觸發時機常見有操作前（BEFORE）與操作後（AFTER）。

啟動器常用於維護資料完整性、執行複雜驗證、同步相關資料，以及記錄異動歷程。它與一般由應用程式明確呼叫的程序不同：啟動器會因資料庫事件自動執行。

解題方法

本題要求說明啟動器的用途，並各舉一項優點與缺點加以論述。作答時先定義「資料事件發生時自動執行程序」，再選擇一個能展現資料庫集中控管效果的優點，以及一個能說明維護與除錯風險的缺點，最後交代其影響。

優點：集中維護資料規則，提升一致性

啟動器在資料庫端執行，因此不論資料是由哪個應用程式、批次作業或使用者介面寫入，只要觸發條件成立，都會套用相同的規則。例如，資料表新增交易資料時，啟動器可同步更新庫存數量或寫入異動紀錄。

核心觀念

本題考查相關子查詢（correlated subquery）、EXISTS、DISTINCT，以及主索引與次要索引的搭配。

• EXISTS 用來判斷子查詢是否至少回傳一筆資料；本題子查詢引用外層的 OrderLine_T.ProductID，因此是相關子查詢。
• DISTINCT 用來去除結果中的重複訂單編號。
• 題目已給定 Product_T 的主索引為 ProductID，以及 OrderLine_T 的主索引為 (OrderID, ProductID)。索引欄位順序會影響查詢能否有效利用索引。

解題方法

逐筆檢查 OrderLine_T 的明細資料，利用其 ProductID 查找 Product_T，篩選 ProductFinish = 'Taipei' 的產品，再輸出符合條件明細所屬的 OrderID。由於同一訂單可能有多筆符合條件的明細，結果須以 DISTINCT 去重。

（一）指令工作與次要索引

此指令查詢「至少包含一項生產地為 Taipei 之產品」的訂單編號，且每個訂單編號只輸出一次。

索引設定可分別考量兩個表：

• **Product_T：**已有以 ProductID 為鍵的主索引。若資料表依 ProductID 排序，此索引可依明細中的 ProductID 快速找到產品，再檢查 ProductFinish。為使檢查產地時更有效，可建立以 ProductFinish 為鍵的次要索引；若採涵蓋索引設計，可將 ProductID 一併納入索引，使查得 Taipei 產品後也能取得其產品編號。
• **OrderLine_T：**主索引為 (OrderID, ProductID)，可支援以訂單編號為首欄的存取，但不利於單獨依 ProductID 查找明細。可建立以 ProductID 為鍵的次要索引，讓系統由符合條件的產品編號反查相關訂單明細，取得 OrderID。

因此，具體索引方向是：Product_T 以 ProductFinish 支援產地篩選，OrderLine_T 以 ProductID 支援產品與訂單明細的連結。實際效益仍取決於資料量、欄位選擇性、資料分布及資料庫管理系統的執行計畫；若 Taipei 產品占比很高，僅靠 ProductFinish 索引的篩選效益可能有限。

（二）改寫為不使用子查詢

可改以 JOIN 連接兩表：