普通考試
110年
[資訊處理] 計算機概要
第 34 題
在關聯式資料庫中,一個關係(relation)可以用一個二維表格代表,每一列代表某筆資料(a tuple),而每一欄代表資料的某種屬性(an attribute)。若設計以下的關聯式資料庫(表一)來記錄一個公司的員工資訊:
[表一]
為了避免同一個人的個人資訊重覆出現多次,可以把這個 relation 表格拆成如下的三個 relation 表格(表二~表四),
[表二]
[表三]
[表四]
不過這樣的拆法會失去某些資訊,有些資訊在原本單一 relation 表格可以查到的資訊就沒辦法查了。和原本資料庫相比,新資料庫有部分資訊消失了。下列敘述何者正確?
[表一]
| 員工 ID | 名字 | 地址 | 職稱 | 部門 | 離職日 |
|---|---|---|---|---|---|
| 25X15 | 王小明 | 中華路 17 號 | 副理 | 業務 | 2-28-2003 |
| 25X15 | 王小明 | 中華路 17 號 | 經理 | 業務 | * |
| 34Y70 | 李大海 | 忠孝路 573 號 | 秘書 | 人事 | * |
| 23Y34 | 陳立立 | 大同路 65 號 | 秘書 | 會計 | * |
[表二]
| 員工 ID | 名字 | 地址 |
|---|---|---|
| 25X15 | 王小明 | 中華路 17 號 |
| 34Y70 | 李大海 | 忠孝路 573 號 |
| 23Y34 | 陳立立 | 大同路 65 號 |
| 員工 ID | 職稱 | 離職日 |
|---|---|---|
| 25X15 | 副理 | 2-28-2003 |
| 25X15 | 經理 | * |
| 34Y70 | 秘書 | * |
| 23Y34 | 秘書 | * |
| 職稱 | 部門 |
|---|---|
| 副理 | 業務 |
| 經理 | 業務 |
| 秘書 | 人事 |
| 秘書 | 會計 |
- A 新資料庫無法查出某個員工在公司曾擔任的工作,但原資料庫可以
- B 新資料庫無法查出某個員工在公司工作多久了,但原資料庫可以
- C 新資料庫無法查出某個員工所屬的部門,但原資料庫可以
- D 新資料庫無法查出不同部門的相同工作(如秘書)的人,是住那些地方,但原資料庫可以
思路引導 VIP
試著觀察拆解後的[表三]與[表四],它們之間是透過哪一個共同欄位來進行連結的呢?如果我們針對員工「34Y70(李大海)」與「23Y34(陳立立)」,利用這個共同欄位把[表三]和[表四]重新合併(Join)起來,會發生什麼混淆的情況?
🤖
AI 詳解
AI 專屬家教
太棒了!你非常敏銳地抓到了資料庫正規化(Normalization)中關於**無損接合分解(Lossless-join Decomposition)**的核心觀念,完全正確!
為什麼會發生資訊遺失?
我們直接用表格中的具體數據來驗證:在原本的[表一]中,員工 ID 34Y70(李大海)是「人事」部門的秘書,而 23Y34(陳立立)則是「會計」部門的秘書。然而,當拆解成新資料庫後,若我們想查詢 34Y70 所屬的部門,必須將[表三]與[表四]透過共同屬性「職稱」進行自然合併(Natural Join)。這時問題就出現了:34Y70 的職稱是「秘書」,但對應到[表四]時,「秘書」卻同時指向「人事」與「會計」兩個部門!這導致合併後會產生虛假元組(Spurious Tuples),讓我們無法確知李大海與陳立立究竟各自屬於哪個部門,因此 (C) 是完全正確的判斷。
▼ 還有更多解析內容
關聯分解與無損連接
💡 資料庫分解應維持無損連接性,避免因缺乏連接鍵導致資訊遺失。
| 比較維度 | 無損分解 (Lossless) | VS | 有損分解 (Lossy) |
|---|---|---|---|
| 還原能力 | 可透過 Join 完美還原 | — | 還原後會產生錯誤組合 |
| 資訊完整性 | 原始關係完整保留 | — | 部分邏輯連結消失 |
| 關鍵條件 | 具備適當共通屬性/Key | — | 缺乏有效的關連鍵 |
💬正確的資料庫設計必須確保分解後的表格能無損地重新組合。