關聯式資料庫入門：什麼是個體？什麼是關係？

前面的文章我們學到了關聯式資料庫的核心特徵：欄位固定、格式統一。

但在真實世界中，資訊是雜亂的。這篇文章要教你如何把日常生活中的資訊，轉換成有條有理的資料表。

我們會透過兩個範例，從簡單到複雜，學會如何找出「個體」和「關係」，並把它們轉換成資料表。

資料結構化的技巧：名詞、動詞、形容詞

在開始之前，先教你一個訣竅：用文法來分析資訊。

當你看到一段文字時，試著找出：

這個技巧可以幫助你快速拆解複雜的資訊。

範例一：建立個體表與關係表

原始資訊

David 的膚色是深褐色。Emily 的膚色是淺褐色。David 和 Emily 在 3 月 15 日結婚了。

步驟一：找出名詞、動詞、形容詞

• 名詞：David、Emily（兩個人物）
• 動詞：結婚（兩個人之間的關係）
• 形容詞：深褐色、淺褐色（膚色的性質）

步驟二：建立個體表

名詞代表「個體」。

這裡有兩個個體：David 和 Emily。但他們都是「人物」，屬於同一類。

在關聯式資料庫中，同一類的個體放在同一張表，每個個體是表中的一筆資料（一列）。

那欄位呢？還記得形容詞代表「性質」嗎？深褐色、淺褐色都是在描述「膚色」這個性質，所以「膚色」就成為欄位。

所以我們建立一張「人物表」，把 David 和 Emily 都放進去：

步驟三：建立關係表

動詞代表「關係」。

「結婚」是 David 和 Emily 之間的關係。這個資訊可以放在人物表嗎？

如果放在人物表，會變成這樣：

看起來可以，但有個問題：同樣的「結婚關係」被記錄了兩次（David 那列記一次，Emily 那列又記一次）。這就是重複儲存。

更好的做法是：把關係獨立成一張表，專門記錄「誰和誰有這個關係」。

所以我們建立一張「結婚表」：

這樣，結婚這件事只記錄一次，乾淨俐落。

思考：結婚表需要記錄膚色嗎？

你可能會想：要不要在結婚表中加入「人物一的膚色」和「人物二的膚色」欄位？

答案是：不需要。

為什麼？因為膚色已經記錄在人物表了。如果你想知道 David 的膚色，只要回去查人物表就好。

這就是關聯式資料庫的精髓：透過關聯來查詢資料，避免重複儲存。

如果你在結婚表也存一份膚色，會有什麼問題？

• 同樣的資料存了兩次，浪費空間
• 如果 David 的膚色要修改，你要改兩張表，很容易漏改

步驟四：補上遺漏的資訊

等等，我們漏了一個資訊：結婚日期。

結婚日期要放在哪裡？人物表還是結婚表？

答案是：結婚表。

因為「結婚日期」是這段「結婚關係」的性質，不是任何一個人的性質。如果 David 和 Emily 沒有結婚，就不會有結婚日期這件事。

💡 重要觀念：關係本身也會有性質。這些性質要放在關係表中，不是個體表。

思考：人物一和人物二的順序重要嗎？

在結婚這個關係中，David 放人物一、Emily 放人物二，跟反過來放有差別嗎？

答案是：沒有差別。

因為「A 和 B 結婚」跟「B 和 A 結婚」是同一件事。這種關係叫做對稱關係。

但不是所有關係都是對稱的，我們在下一個故事會看到。

範例二：當關係變得更複雜

原始資訊

David 和 Emily 結婚了。這使得 Jason 震驚不已，畢竟 David 是 Jason 最好的朋友，而 Emily 是 Jason 的妹妹。

這個故事複雜多了，讓我們一步步拆解。

步驟一：找出名詞、關係、形容詞

• 名詞：David、Emily、Jason（三個人物）
• 關係：結婚、朋友、妹妹（三種人物之間的關係）
• 形容詞：最好的（朋友關係的程度）
• 事件：震驚（對某件事的反應）

步驟二：建立個體表

人物表：

步驟三：建立關係表

這個故事有三種關係，所以需要三張關係表。

結婚表：

朋友表：

但等等，原文說的是「最好的朋友」，不只是朋友而已。「最好的」代表友好程度是最高的。

這個「友好程度」是誰的性質？

• 不是 Jason 的性質（Jason 本身沒有「友好程度」這個屬性）
• 不是 David 的性質（David 本身也沒有）
• 是「Jason 和 David 的朋友關係」的性質

還記得範例一提到的嗎？「結婚日期」是結婚關係的性質，不是任何一個人的性質。這裡也一樣：關係本身也會有性質。

不過，「友好程度」和「結婚日期」有一點不同：

• 結婚日期：單純描述 David 和 Emily 這段關係本身的性質
• 友好程度：不只描述 Jason 和 David 的關係，還隱含了「和其他朋友比較」的意思

「最好的朋友」代表 Jason 和 David 的友好程度，比 Jason 和其他朋友的友好程度都高。所以「友好程度」這個性質，是用來和其他關係做比較的。

但不管是哪一種，它們都是「關係的性質」，要記錄在關係表中。

所以我們需要多一個「友好程度」欄位：

這樣才能區分「普通朋友」和「最好的朋友」。從表中可以看出，Jason 和 David 的友好程度是「高」，比 Jason 和 Kevin 的「中」還要高，所以 David 是 Jason「最好的朋友」。

親屬表：

這裡要注意一件事：親屬關係的順序很重要。

如果我們把人物和親屬對調：

這樣就變成「Emily 的妹妹是 Jason」，意思完全不對了！

「Jason 的妹妹是 Emily」跟「Emily 的妹妹是 Jason」是不同的意思。這種關係叫做非對稱關係。

為什麼親屬關係是非對稱的？關鍵在於「親屬類型」這個欄位。

還記得我們說過「關係本身也會有性質」嗎？「親屬類型」就是親屬關係的性質。而「妹妹」這個類型是有方向性的：A 的妹妹是 B，不代表 B 的妹妹是 A。

相比之下，結婚關係沒有這種「有方向性的性質」，所以是對稱的。設計關係表時，要特別注意關係的性質是否會影響順序。

關係的對稱性整理：

步驟四：記錄事件

還記得我們把「震驚」歸類為「事件」嗎？

但仔細想想，「震驚」跟前面的「結婚」、「朋友」、「妹妹」其實很像：

• 結婚：David 和 Emily 之間的關係
• 朋友：Jason 和 David 之間的關係
• 妹妹：Jason 和 Emily 之間的關係
• 震驚：Jason 和 ？？？ 之間的關係

它們的結構都是「某個東西」和「另一個東西」之間的連結。

差別在於：前三個是「人和人」之間的關係，而「震驚」是「人和某個事件」之間的情緒關係。

所以「震驚」也可以用關係表來記錄。我們建立一張「震驚表」：

思考：Jason 震驚的對象是什麼？

Jason 是對誰震驚？是對 David 震驚？還是對 Emily 震驚？

都不是。Jason 是對「David 和 Emily 結婚」這件事震驚。

也就是說，震驚的對象不是一個「人」（個體），而是「David 和 Emily 的結婚」（關係）。

讓我們整理一下目前出現的關係：

• 結婚關係：David 和 Emily 之間的關係
• 震驚關係：Jason 和「結婚關係」之間的關係

發現了嗎？「震驚關係」的其中一方，不是一個人，而是另一個「關係」。

換句話說：

• 前面的關係（結婚、朋友、妹妹）都是「個體 和 個體」之間的連結
• 但震驚是「個體（Jason）和 關係（David 和 Emily 的結婚）」之間的連結

這是一個很重要的觀念：關係不只存在於個體之間，也可以存在於個體和關係之間，甚至關係和關係之間。

日常生活中其實很常見這種情況，例如：

• 「我很羨慕他們的婚姻」→ 我（個體）和 他們的婚姻（關係）之間的情緒關係
• 「這段友誼影響了那段合作」→ 友誼（關係）和 合作（關係）之間的影響關係

從資訊到資料表的五個步驟

經過這兩個故事，我們可以整理出轉換的步驟：

第一步：找出個體

從資訊中找出「名詞」，這些就是個體。每種個體建立一張表。

第二步：找出個體的性質

從資訊中找出「形容詞」，這些是個體的性質，會變成個體表的欄位。

第三步：找出個體之間的關係

從資訊中找出「動詞」，這些是個體之間的關係。每種關係建立一張關係表。

第四步：找出關係的性質

關係本身也會有性質，例如：結婚日期、友好程度。這些會變成關係表的欄位。

第五步：找出個體與關係之間的關係

有時候，個體和關係之間也會有關係，例如：Jason 對「David 和 Emily 結婚」這件事感到震驚。這種情況需要另外建表來記錄。

什麼是 Schema（資料庫架構）？

當你把所有的表和欄位都設計好之後，這個整體的結構就叫做 Schema（資料庫架構）。

Schema 這個字有很多翻譯：架構、模式、綱要。在資料庫的領域，我們通常翻譯成「架構」。

Schema 包含了：

• 有哪些資料表
• 每張表有哪些欄位
• 表和表之間的關聯

Schema 一旦設計好，通常不會頻繁變動。所以在設計的時候要想清楚，把結構設計得越精簡越好，避免重複的資料。

下一篇文章，我們會學習如何把 Schema 設計得更漂亮、更精簡。

小結

這篇文章學到的重點：

1. 用文法分析資訊：名詞→個體、動詞→關係、形容詞→性質
2. 個體和關係都需要建表：個體有個體表，關係有關係表
3. 避免重複儲存：透過關聯來查詢資料，不要在多張表中重複儲存同樣的資訊
4. 關係本身有性質：例如結婚日期、友好程度，這些要放在關係表中
5. 關係之間也可以有關係：例如對某件事感到震驚
6. 注意關係的對稱性：有些關係順序重要（親屬），有些不重要（結婚、朋友）
7. Schema 是資料庫的整體架構：包含所有表和欄位的設計