109 地方特考三等 資訊處理 資料庫應用 考古題詳解
第 一 題20 分
在資料模型中，限制（Constraints）是資料庫狀態（Database States）任何時刻必須滿足的條件，請論述實體關聯模型（ER Models）有關實體間對應的兩個限制及關聯模型（Relational Models）的三個限制。另外，關聯資料庫模型如何表示上述實體關聯模型的兩個限制？
登入後即可作答並保存紀錄。
核心觀念
本題考資料模型中的完整性限制，分成兩部分：
- ER 模型的實體間對應限制：描述實體透過關聯參與時，彼此可如何對應。
- 關聯模型的三種限制：確保資料表中的資料符合鍵值與參照規則。
ER 模型的兩項對應限制是基數比（cardinality ratio）與參與限制（participation constraint）；關聯模型的三項限制是鍵限制（key constraint）、實體完整性（entity integrity）與參照完整性（referential integrity）。
解題方法
先辨認題目問的兩種模型，再分別列出限制名稱及其意義。最後說明如何將 ER 模型的基數比與參與限制，轉換為關聯模型中的外鍵、唯一性與非空等約束。
一、ER 模型的兩個對應限制
1. 基數比（Cardinality Ratio）
描述一個實體透過某關聯，最多可以對應到另一實體的幾個實體。常見型態如下：
- 一對一（1:1）：兩端的每個實體至多對應另一端一個實體。
- 一對多（1:N）：一端的每個實體可對應另一端多個實體；另一端則至多對應一個。
- 多對一（N:1）：與一對多相同，只是觀察方向相反。
- 多對多（M:N）：兩端的每個實體都可對應另一端多個實體。
基數比限制的是「最多可對應幾個」，不表示每個實體都一定要參與關聯。
2. 參與限制（Participation Constraint）
描述某實體集合中的實體是否必須參與關聯：
- 全部參與（total participation）：每個實體都必須至少參與一次該關聯。
- 部分參與（partial participation）：允許有實體不參與該關聯。
因此，參與限制表示「至少要參與幾次」；基數比表示「最多可對應幾個」。兩者描述的面向不同。
二、關聯模型的三個限制
1. 鍵限制（Key Constraint）
資料表的鍵值必須能唯一識別每一筆資料。主鍵不可重複；候選鍵也各自具有唯一性。
2. 實體完整性（Entity Integrity）
第 二 題20 分
一家公司 Company 的資料，擬設計一資料庫來儲存。經系統分析後，得到如下需求：
-
Company 公司由許多部門（department）組成。每一部門有一部門代碼（dept-id）、一部門名稱（dept-name），一部門會有多個地點（dept-loc），每一部門有一員工擔任主管，並記錄開始擔任主管日期（start_date）。部門代碼可區別不同部門。
一個部門可以承接許多計畫（project），但一計畫僅由一部門承接。每一計畫有計畫代碼（proj-id）、名稱（proj-name）及計畫說明（proj-descript），計畫代碼可區別不同計畫。
-
一部門由許多員工（employee）組成。每一員工有員工代碼（emp-id）、員工姓名（emp-name）、員工性別（emp-sex）與員工生日（emp-birthdate）。每一員工隸屬於一部門，每一員工代碼可區別不同員工。
員工會互相監督（supervision），每位員工最多有一位直屬監督者，但可能會直接監督多位其他員工。
-
一員工可以扶養多位眷屬（dependent）。每一眷屬有眷屬代碼（dep-id）、眷屬姓名（dep-name）與眷屬生日（dep-birthdate），但一眷屬只能由一員工來扶養。
-
一員工可以參與許多計畫，一計畫也可許多員工來參與，每一員工參與的計畫有一參與的時數（hours）。
請劃出 Company 公司實體關聯綱要（Entity-Relationship Schema），包括屬性（Attributes）、實體型態、關聯型態與相關限制。
登入後即可作答並保存紀錄。
核心觀念
本題考查 ER 模型的實體、屬性、主鍵、關聯型態與基數限制，並包含多值屬性、遞迴關聯、弱實體及關聯屬性。
判讀時先找出可獨立識別的對象作為實體，再將描述其性質的資料列為屬性；接著依「一方可對應多少另一方」判斷關聯基數。題目未要求轉換成關聯式資料表，因此以 ER 綱要表達即可。
解題方法
以實體及其識別屬性為起點，再逐段對照題目需求，整理如下：
| 實體型態 | 屬性 | 主鍵 |
|---|---|---|
| 部門 Department | dept-id、dept-name、dept-loc（多值） | dept-id |
| 員工 Employee | emp-id、emp-name、emp-sex、emp-birthdate | emp-id |
| 計畫 Project | proj-id、proj-name、proj-descript | proj-id |
| 眷屬 Dependent | dep-id、dep-name、dep-birthdate | 見下方說明 |
dept-loc 是多值屬性，因為每一部門可以有多個地點。若以 Chen ER 圖表示，應以雙橢圓表示。
各項關聯與限制如下：
| 關聯型態 | 參與實體 | 基數限制與說明 |
|---|---|---|
| 組成／隸屬 | Department—Employee | 一個部門有多位員工；每位員工隸屬一個部門，為 。員工必須參與此關聯；部門至少有一位員工。 |
| 承接 | Department—Project | 一個部門可承接多個計畫；每個計畫僅由一個部門承接，為 。計畫必須有承接部門；部門可沒有計畫。 |
| 主管 | Employee—Department | 每個部門恰有一位主管；一位員工可主管零個或多個部門，為員工對部門的 。關聯屬性為 start_date；每個部門都必須參與此關聯。 |
| 監督 supervision | Employee—Employee | 遞迴關聯。員工最多有一位直屬監督者；一位員工可監督零位或多位員工，為 。需以角色名稱區分「監督者」與「被監督者」。 |
| 扶養 | Employee—Dependent | 一位員工可扶養多位眷屬；每位眷屬只由一位員工扶養，為 。眷屬必須參與此關聯。 |
| 參與 | Employee—Project | 員工可參與多個計畫，計畫也可有多位員工參與，為 。hours 是此關聯的屬性，表示特定員工參與特定計畫的時數。 |
題目明確指出 dept-id、emp-id、proj-id 可區別各自實體，因此分別作為主鍵。眷屬則有兩種常見建模方式：若 dep-id 在公司全體唯一，Dependent 可視為一般實體，以 dep-id 為主鍵；若 dep-id 只在同一員工所扶養的眷屬中唯一，Dependent 應建模為弱實體，其識別鍵為「員工 emp-id + dep-id」。
第 三 題20 分
在資料庫的實作及環境中，同步控制（Concurrency Control）在交易（Transactions）處理是很重要的技術，請論述兩階段鎖定（Two-phase Locking）與時戳（Timestamps）技術及其不同處。
登入後即可作答並保存紀錄。
核心觀念
本題考查資料庫並行控制的兩種主要機制：兩階段鎖定（Two-phase Locking, 2PL）與時戳排序（Timestamp Ordering）。兩者都用來確保同時執行的交易，其結果與某種串行執行順序等價，亦即維持衝突可串行化；差別在於，2PL 透過鎖定資料項目限制操作時機，時戳技術則依交易的時間順序判斷操作能否執行。
常見鎖定模式有：
- 共享鎖（Shared lock, S-lock）：讀取資料時使用；多個交易可以同時持有同一資料項目的共享鎖。
- 排他鎖（Exclusive lock, X-lock）：寫入資料時使用；同一資料項目上，排他鎖不能與其他共享鎖或排他鎖並存。
解題方法
一、兩階段鎖定（2PL）
2PL 規定每個交易的鎖定操作必須分成兩個階段：
- 成長階段（Growing phase）：可以取得新鎖或升級鎖，但不能釋放任何鎖。
- 縮減階段（Shrinking phase）：可以釋放鎖或降級鎖，但不能再取得新鎖。
兩階段的分界點稱為鎖定點（Lock point），也就是交易取得最後一把鎖的時刻。所有交易都遵守 2PL，可確保衝突可串行化；其等價串行順序可依各交易的鎖定點排列。
例如，交易 先取得 、再取得 ，之後釋放 、再釋放 ，符合 2PL。若 釋放 後又取得 ，便違反 2PL，因為交易已進入縮減階段，不能再取得新鎖。
2PL 的常見變形包括：
- 嚴格兩階段鎖定（Strict 2PL）：排他鎖至少保留到交易提交或中止，可避免其他交易讀取尚未提交的資料，並簡化復原。
- 強嚴格兩階段鎖定（Rigorous 2PL）：共享鎖與排他鎖都保留到交易提交或中止。
- 保守兩階段鎖定（Conservative 2PL）：交易開始前先取得所需的全部鎖；若無法全數取得，就不開始執行。此法可避免死結，但須事先知道交易所需資料項目。
基本 2PL 雖能保證衝突可串行化，仍可能發生死結；也可能因過早釋放排他鎖，造成其他交易讀取未提交資料，形成連鎖回復風險。
二、時戳排序（Timestamp Ordering）
時戳技術在交易開始時，依系統給予每個交易一個唯一時戳 。時戳較小的交易視為較早，系統必須讓衝突操作符合此時戳所決定的順序。
對每個資料項目 ，維護：
- ：曾成功讀取 的交易中，最大的時戳。
- ：曾成功寫入 的交易中，最大的時戳。
第 四 題20 分
現在的臉書與 LINE 有大量的資料，如應用人工智慧來發掘（Discover）相關關鍵詞，以便了解親友對產品的偏好，其中需要很大量資料來當作訓練與測試資料，以訓練出好的學習模型（Learning Models），請寫出資料庫設計過程（Database Design Process），設計資料庫以儲存臉書與 LINE 的大量資料（特別留意臉書與 LINE 資料庫特性），並論述每一過程。
登入後即可作答並保存紀錄。
核心觀念
本題考查資料庫設計程序，以及社群媒體資料的特性如何影響資料庫選型與架構。臉書與 LINE 的資料不只有文字，還包括使用者、好友關係、群組、訊息、圖片、影片、表情符號、時間戳記及互動紀錄；資料量大、持續快速新增，且格式多樣。設計時應同時考量資料擷取、訓練與測試資料管理、查詢效能、擴充能力及隱私安全。
資料庫設計通常依序進行：需求分析、概念設計、邏輯設計、正規化與模式調整、實體設計、建置與測試、維護與演進。各階段會反覆修正，但答題時應交代每階段的產出及其與本題需求的關係。
解題方法
先由人工智慧關鍵詞探索的目的，整理資料來源、資料項目與使用情境；再以概念模型描述資料間的關係，轉換成適當的資料模型，最後決定儲存、索引、分割、複寫及安全策略。由於社群資料具有大量、快速、類型多樣等特性，不宜將所有資料硬塞進單一傳統關聯式資料庫；可採用多模型、分層儲存架構，依資料性質選擇儲存方式。
資料庫設計程序與本題應用
一、需求分析
確認資料來源、資料內容、使用者及系統需求。
- 資料來源：臉書貼文與留言、LINE 個人或群組訊息，以及可合法取得的互動紀錄。
- 主要資料：使用者識別碼、訊息識別碼、發送者、接收對象或群組、時間、文字內容、附件位置、語言、主題標籤、互動紀錄。
- 分析需求：依時間、使用者、群組或產品主題搜尋資料，產生關鍵詞與偏好特徵，並建立訓練集、驗證集及測試集。
- 非功能需求：大量匯入、持續寫入、平行分析、容錯備援、權限控管、個人資料保護及資料保存期限。
需求分析的產出是需求規格與資料字典。必須特別界定資料取得範圍與可使用目的；個人訊息涉及隱私，應以授權、去識別化、最小權限與存取稽核控制使用。
二、概念設計
以 ER 模型描述主要實體、屬性及關係，先不拘泥於特定資料庫產品。
可建立以下實體：
- 使用者（User）：使用者代碼、平台代碼、必要的匿名化識別值。
- 訊息（Message）：訊息代碼、發送者、時間、文字內容、訊息類型。
- 群組（Group）：群組代碼、平台代碼及必要的群組資訊。
- 附件（Attachment）：附件代碼、檔案類型、儲存位置及檔案雜湊值。
- 標註（Annotation）：訊息、關鍵詞或標籤、標註者或標註程序、標註版本。
- 資料集項目（DatasetItem）：訊息代碼、資料集代碼、資料用途及資料切分別。
使用者與訊息通常是一對多關係；訊息與附件為一對多；使用者與群組則可能是多對多，可用群組成員關係表示。若要呈現好友關係，可另設使用者間的關係實體。概念模型應避免把「訊息內容」、「群組成員」及「AI 標註」混為同一個實體。
三、邏輯設計
將概念模型轉換成資料庫邏輯模式。若使用關聯式資料庫，可設計：
User(user_id, platform, pseudonym_id)Message(message_id, platform, sender_id, group_id, sent_at, content, message_type)Attachment(attachment_id, message_id, media_type, object_uri, checksum)GroupMember(group_id, user_id, joined_at)Annotation(message_id, label, keyword, model_version, created_at)
第 五 題20 分
在關聯式資料庫模型，何謂關聯代數（Relational Algebra）？為何需要關聯代數？何謂關聯完全（Relationally Complete）？又商業化的資料庫管理系統會用到的資料庫查詢語言是什麼？與關聯代數有何關係？資料庫處理器（Run-time Database Processor）如何處理此查詢語言？
登入後即可作答並保存紀錄。
核心觀念
本題考查關聯式資料庫的理論查詢基礎及其與實務查詢語言的關係。答題時應依序說明：關聯代數的定義與用途、關聯完全的意義、商業資料庫使用的查詢語言，以及資料庫處理器如何執行查詢。
**關聯代數（Relational Algebra）**是一種以關聯（資料表）為運算對象的程序式查詢語言。它定義一組運算，讓使用者指定如何從一個或多個關聯取得所需結果。常見運算包括選擇（Selection）、投影（Projection）、聯集（Union）、差集（Set Difference）、笛卡兒積（Cartesian Product）與重新命名（Rename）；也常使用交集、連接（Join）及除法（Division）等衍生或擴充運算。
**為何需要關聯代數：**它提供精確、形式化的資料操作基礎，可用來描述查詢、推導查詢等價式，並協助資料庫系統進行查詢最佳化與執行計畫選擇。它也是理解關聯式查詢語言及資料庫內部處理方式的重要理論工具。
**關聯完全（Relationally Complete）：**若某種查詢語言在表達能力上至少能表達關聯代數的基本運算，便稱為關聯完全。換言之，對可由關聯代數表達的查詢，該語言也能表達其等價查詢。這是對查詢表達能力的描述，不代表每種語法或實作方式都與關聯代數完全相同。
解題方法
依「理論模型—商用語言—執行流程」作答：
- 先把關聯代數定位為操作關聯的形式化程序式查詢語言，並點出它的運算及理論用途。
- 再說明商業化資料庫管理系統普遍使用 SQL（Structured Query Language）。
- 說明 SQL 與關聯代數的關係：SQL 是實務上使用的宣告式查詢語言，其核心查詢能力具有關聯完全性；SQL 查詢可在概念上轉換成關聯代數運算，再由系統最佳化及執行。
- 最後交代資料庫處理器的流程：解析與驗證查詢、轉換查詢表示、最佳化、產生並執行計畫，透過儲存管理元件存取資料，最後回傳結果。
資料庫處理器的處理流程
使用者提出 SQL 查詢後，資料庫處理器通常依下列階段處理：