114 高普考高考二級 資訊處理 高等資料庫設計 考古題詳解
第 一 題25 分
假設我們要為某政府機關設計一個資料庫系統，以管理該機關發包的各項工程與相關資訊，經分析後得到下列需求：
-
每項工程案需要記錄其工程編號、工程名稱、發包日期與施作地點，而且工程編號不可重複，以用來辨識不同的工程案。
-
每個廠商皆須登記其統一編號、公司名稱、聯絡人姓名與電話。
-
一個工程案只能由一位廠商承包，但一位廠商可以承包多個工程案。
-
每個工程案只會由機關內的一位員工負責，但一位員工可以負責多件工程案。每位員工需記錄其員工編號、員工姓名、職稱與部門名稱，且每位員工的編號皆不同。
-
有些工程在執行過程中可能會進行多次查核，每次查核需記錄查核日期與查核結果，且查核紀錄的唯一識別方式是「工程編號」和「查核日期」的組合。
請根據上述所有需求畫出一個實體關係圖（Entity-Relationship Diagram, ER Diagram），注意圖中必須標明實體集合（Entity Set）、關係集合（Relationship Set）、屬性（Attribute）、主鍵（Primary Key）和對應數量限制（Mapping Cardinality）等。
另外，請特別使用弱實體集合（Weak Entity Set）來表示查核資料，並詳述弱實體和一般實體的不同之處為何，以及你的表示法傳遞了什麼特別的資料限制或意義。
登入後即可作答並保存紀錄。
核心觀念
本題考查 ER 模型中的實體集合、關係集合、屬性、主鍵、對應數量限制，以及弱實體集合的辨識與表示。
- 實體集合（Entity Set）：具有共同屬性的一類物件，例如工程案、廠商、員工。
- 關係集合（Relationship Set）：描述實體集合之間的關聯，例如工程案由廠商承包、由員工負責。
- 主鍵（Primary Key）：能唯一辨識實體的屬性。
- 對應數量限制（Mapping Cardinality）：描述關係兩端的數量，例如一對多（）。
- 弱實體集合（Weak Entity Set）：本身沒有足以唯一辨識個體的完整主鍵，須依附於擁有者實體集合，並搭配部分鍵才能唯一辨識。
本題沒有涉及法條。
解題方法
先依需求找出可獨立辨識的實體，再整理各自屬性與主鍵；接著根據「只能由一位」或「可以多件」判斷關係的對應數量限制。最後將查核資料判斷為弱實體，因其識別方式必須依賴工程編號。
1. 實體集合與屬性
| 實體集合 | 屬性 | 主鍵 |
|---|---|---|
工程案 工程案 | 工程編號、工程名稱、發包日期、施作地點 | 工程編號 |
廠商 廠商 | 統一編號、公司名稱、聯絡人姓名、電話 | 統一編號 |
員工 員工 | 員工編號、員工姓名、職稱、部門名稱 | 員工編號 |
工程編號、統一編號及員工編號均可唯一辨識各自實體，因此分別作為主鍵。
2. 關係集合與對應數量限制
- 承包（廠商—工程案）：一位廠商可以承包多項工程案，每項工程案只能由一位廠商承包，因此為廠商對工程案的 關係。
- 負責（員工—工程案）：一位員工可以負責多項工程案，每項工程案只由一位員工負責，因此為員工對工程案的 關係。
- 查核（工程案—查核紀錄）：一項工程案可有多筆查核紀錄，每筆查核紀錄只屬於一項工程案，因此為工程案對查核紀錄的 關係。查核紀錄是弱實體集合。
3. ER 圖
圖例：方框表示實體集合；雙框表示弱實體集合；菱形表示關係集合；雙菱形表示識別關係；底線表示主鍵；虛線底線表示部分鍵。1 與 N 標示關係兩端的對應數量。
第 二 題25 分
假設在某關聯式資料庫中定義了一個 BOOK 表格，其中包含三個字串型態的屬性，分別為 ISBN、Title、Author。若資料庫管理者為該表格的 Author 屬性建立了一個索引（Index），且該索引是依照 B+-tree 的結構所建立。
首先請列舉數筆範例資料，然後描繪出對應的索引結構。接著，請說明此索引有助於提升下述哪個查詢句的查詢效率，並詳述你的理由：
查詢句一： select Author from BOOK where Title = ‘相對論’;
查詢句二： select Title from BOOK where Author = ‘Einstein’;
登入後即可作答並保存紀錄。
核心觀念
本題考查 B+-tree 索引與查詢條件、輸出欄位的關係。索引依哪個屬性建立，主要就能依該屬性的值快速搜尋；若查詢條件使用索引欄位，便能先定位符合的索引項目，再取得所需資料。
本題索引建立於 Author，因此索引鍵是作者值。B+-tree 的內部節點用來導引搜尋，葉節點依索引鍵排序，並保存索引鍵及對應資料列的位置（或主鍵）。
解題方法與索引示意
以下假設資料表包含這幾筆範例資料：
| ISBN | Title | Author |
|---|---|---|
| 978-1 | 相對論 | Einstein |
| 978-2 | 時間簡史 | Hawking |
| 978-3 | 廣義相對論 | Einstein |
| 978-4 | 宇宙簡史 | Hawking |
| 978-5 | 物理學的未來 | Feynman |
索引依 Author 排序。同一作者可以對應多筆資料，因此索引葉節點須保留各筆資料的位置。以下以簡化的 B+-tree 示意；實際節點容量與分裂方式取決於索引參數及資料量。
[Hawking]
/ \
/ \
[Einstein → 978-1, 978-3] → [Feynman → 978-5, Hawking → 978-2, 978-4]
葉節點依作者值排序，並以箭頭連結，方便依序掃描。實際索引常以資料列位址或主鍵作為指標；上圖以 ISBN 簡化表示。
判斷查詢是否受益，重點是看 WHERE 條件是否以 Author 限定資料列。SELECT 指定輸出哪些欄位，與索引能否加速搜尋是不同的考量。
查詢句分析
查詢句一
select Author from BOOK where Title = ‘相對論’;
不會因本題的 Author 索引而有效加速搜尋。
第 三 題25 分
假設資料庫系統中定義了下列兩個表格，其中屬性 Bid 代表書籍編號，屬性 Uid 代表使用者編號，且表格中的所有屬性皆為字串（varchar）型態：
BOOK（Bid, Title, Author）
BORROWER（Uid, Bid, Date）
另外觀察到本系統的使用者經常需要執行下述 SQL 查詢句：
select Uid, Title from BOOK, BORROWER where BOOK.Bid = BORROWER.Bid;
假設系統中原本並沒有定義任何索引，而我們希望利用樹狀結構的索引（如 B+-tree 或 B-tree）來提升上述 SQL 的查詢處理效率。
首先，請以 SQL 標準語法為上述的一個或兩個表格的特定屬性定義索引，並詳述你選擇為哪些屬性定義索引的理由。
其次，請自行設計合適的資料範例，針對你所定義的一個或數個索引具體畫出對應的樹狀結構，並以該實例說明你所設計的索引結構如何提升上述 SQL 句的查詢效率。
登入後即可作答並保存紀錄。
核心觀念
本題考查索引鍵選擇與索引協助連接（join）。查詢以 BOOK.Bid = BORROWER.Bid 連接兩表，並輸出 BORROWER.Uid 與 BOOK.Title。因此，索引應優先設在連接欄位 Bid 上，讓資料庫能快速找到另一表中 Bid 相同的資料。
樹狀索引（如 B+-tree）依鍵值排序，能有效支援鍵值搜尋。若索引採用覆蓋查詢所需欄位，資料庫還能直接從索引取得部分輸出欄位，減少讀取資料表的次數。
解題方法
本解答在兩表的 Bid 欄位建立 B+-tree 索引：
CREATE INDEX idx_book_bid
ON BOOK (Bid);
CREATE INDEX idx_borrower_bid
ON BORROWER (Bid);
BOOK.Bid 與 BORROWER.Bid 都是連接條件中的欄位，兩者皆建立索引，可供查詢最佳化器選擇較有效率的連接策略。若只有一側有索引，另一側仍可能需要大量掃描；兩側都有索引，則可依資料筆數、索引高度與資料分布選擇從較小的一側開始查找。
題目未指定欄位唯一性，因此索引不宣告 UNIQUE。同一本書可被多位使用者借閱，BORROWER.Bid 也可重複；而題目未明確保證 BOOK.Bid 唯一，故不額外假設其唯一性。
索引範例與查詢效率
假設資料如下：
BOOK
| Bid | Title | Author |
|---|---|---|
| B01 | 資料庫系統 | 王一 |
| B02 | 演算法 | 李二 |
| B03 | 作業系統 | 陳三 |
| B04 | 網路概論 | 林四 |
BORROWER
| Uid | Bid | Date |
|---|---|---|
| U01 | B02 | 114-01-03 |
| U02 | B01 | 114-01-05 |
| U03 | B02 | 114-01-08 |
| U04 | B04 | 114-01-10 |
| U05 | B03 | 114-01-11 |
以下以階度為 3 的簡化 B+-tree 示意索引。實際節點容量會依系統頁面大小與鍵值長度而定。
idx_book_bid
[ B03 ]
/ \
[ B01 | B02 ] [ B03 | B04 ]
idx_borrower_bid
[ B02 ]
/ \
[ B01 | B02 ] [ B02 | B03 | B04 ]
第 四 題25 分
關聯式資料庫雖然被廣為使用，但是不同類型的資料庫也日漸受到重視，其中包含文件資料庫（Document Database）和圖形資料庫（Graph Database）。
請針對此兩種類型，分別提供一個代表性的系統軟體，並詳述該軟體處理的資料型態為何，以及舉例說明合適的應用場景。
登入後即可作答並保存紀錄。
核心觀念
本題考查文件資料庫與圖形資料庫的資料模型、代表性系統，以及各自適合處理的資料與應用情境。作答時，須指出系統名稱，說明它如何組織資料，再以符合該資料模型的場景舉例。
- 文件資料庫（Document Database）：以文件為基本儲存單位，常見格式為 JSON、BSON 或類似的鍵值結構。文件可包含巢狀物件與陣列，適合欄位結構多變、需要整份讀取或更新的資料。
- 圖形資料庫（Graph Database）：以節點（Node）表示實體，以邊（Edge）表示實體間的關係，並可在節點與邊上附加屬性。它著重關係的表示與遍歷，適合關係複雜、需要查詢多層關聯的資料。
解題方法
依序回答三項：代表系統、處理的資料型態、合適的應用場景。場景要能凸顯該資料模型的優點：文件資料庫強調文件結構彈性；圖形資料庫強調關係及路徑查詢。
作答要點
一、文件資料庫：MongoDB
MongoDB 是代表性的文件資料庫。它以 BSON 文件儲存資料，BSON 是可表示多種資料型態的二進位文件格式，支援巢狀文件、陣列及不同欄位組合。
例如，商品資料可直接以一份文件記錄名稱、價格、規格與評論；不同商品也能各自擁有不同規格欄位。適合用於商品型錄、內容管理、使用者設定檔或事件資料等欄位可能增減、結構不完全一致的場景。