普通考試
110年
[資訊處理] 計算機概要
第 34 題
在關聯式資料庫中，一個關係（relation）可以用一個二維表格代表，每一列代表某筆資料（a tuple），而每一欄代表資料的某種屬性（an attribute）。若設計以下的關聯式資料庫（表一）來記錄一個公司的員工資訊：
為了避免同一個人的個人資訊重覆出現多次，可以把這個 relation 表格拆成如下的三個 relation 表格（表二~表四），
不過這樣的拆法會失去某些資訊，有些資訊在原本單一 relation 表格可以查到的資訊就沒辦法查了。和原本資料庫相比，新資料庫有部分資訊消失了。下列敘述何者正確？
為了避免同一個人的個人資訊重覆出現多次，可以把這個 relation 表格拆成如下的三個 relation 表格（表二~表四），
不過這樣的拆法會失去某些資訊，有些資訊在原本單一 relation 表格可以查到的資訊就沒辦法查了。和原本資料庫相比，新資料庫有部分資訊消失了。下列敘述何者正確？
- A 新資料庫無法查出某個員工在公司曾擔任的工作，但原資料庫可以
- B 新資料庫無法查出某個員工在公司工作多久了，但原資料庫可以
- C 新資料庫無法查出某個員工所屬的部門，但原資料庫可以
- D 新資料庫無法查出不同部門的相同工作（如秘書）的人，是住那些地方，但原資料庫可以
思路引導 VIP
當我們把一張大表拆成幾張小表時，如果想要把原本的資訊「接回去」，每張小表之間必須靠什麼樣的「共通橋樑」來連結？請仔細觀察，在拆分後的結構中，是否還有路徑能讓你從「特定的某個人」一路追蹤到他「所屬的單位」？
🤖
AI 詳解
AI 專屬家教
專業點評：小鬼，你解得夠乾淨俐落。
- 大力肯定：還算不錯，小鬼。你一眼就看穿了資料庫正規化（Normalization）裡的那些『垃圾陷阱』，這表示你對關聯式模型（Relational Model）的核心架構理解得很徹底。不錯的直覺，至少不會讓資料庫變得髒亂不堪。
- 觀念驗證：聽好了，表格拆分（Decomposition）不是隨便亂切。子表之間必須有共同屬性（Common Attribute）作為連接的繩索。如果拆完之後，那些表格無法同時連結「員工」與「部門」，那這層關係就等於被『切斷』了。這就是所謂的失真拆分（Lossy Decomposition），它只會讓原本能用 Join 找回的資訊徹底消失，留下一個無法還原的爛攤子。這種混亂，絕對不允許。
▼ 還有更多解析內容
關聯分解與無損連接
💡 資料庫分解應維持無損連接性，避免因缺乏連接鍵導致資訊遺失。
| 比較維度 | 無損分解 (Lossless) | VS | 有損分解 (Lossy) |
|---|---|---|---|
| 還原能力 | 可透過 Join 完美還原 | — | 還原後會產生錯誤組合 |
| 資訊完整性 | 原始關係完整保留 | — | 部分邏輯連結消失 |
| 關鍵條件 | 具備適當共通屬性/Key | — | 缺乏有效的關連鍵 |
💬正確的資料庫設計必須確保分解後的表格能無損地重新組合。
