資料模型 (Data Model)

昨天我們討論了資料庫管理系統 (RDMS) 很重要的工作是有系統的去管理有結構的資料。今天我們要來進一步拆解這個結構。

資料模型專門用來形容一份資料。一般來說這個模型有三個元素
(1) 資料的結構: 我們怎麼儲存這些資料
(2) 可以對這個資料進行的操作: 對這些資料我們可以做哪些操作 (例如說要如何存取資料)
(3) 資料的限制: 這些資料有哪些限制 (例如說:資料必須要是數字而非文字)

關聯式資料模型 (Relational Data Model)

在我們踏入關聯式資料庫之前，我們要先解釋接下來幾天我們會使用的名詞定義。
關聯式資料模型世界中，我們要做的是定義不同資續之間的關聯，並且用一個一個的表格來整理，每一個表格表達的是某個「關係」。讓我們來看一個實際的例子。
讓我們想像一下一間販售一些簡單的食物和飲品的輕食店。首先我們有一個菜單，讓我們用下面這個表格(Table)來舉例:

Menu Table

這個菜單表格很簡單，它列舉了這間輕食店販售的品項，我們看到每欄 (Column) ，也就是 Menu ID, Item, Price 和 Type，表示的是菜單這個東西的屬性 (Attribute)。每一列 (Row) 是一筆資料，又稱作資料集合 (Tuples). 如果寫過Python的人可能會覺得這個單字很熟悉，沒錯它是類似的概念，所以在這個實例 (Instance) 中的第一個資料集合可以以下面方式表示:

(M001, Lemon Cake, 80, Cake)

注意到上面的實例是動態的，也就是這個關係中的實例是會隨著時間增加與減少。注意資料集合 (Tuple) 是一筆資料特徵的集合，對比實例 (Instance)表示的是某個關係表格中所有不重複的資料。
另外一個常用的詞彙叫做綱要 (Schema)。綱要包含了這個關係表格中資料間的關係。在關聯式資料庫中每個屬性的定義域限制(Domain Constraint) 也會在綱要中顯示，所以上面這個表格的表格綱要可以簡寫如下:

Menu(MenuID: string, Item: string, Price: integer, Type: string)

在這裡 Menu 表中的綱要是一個集合而非列表，這些屬性是沒有順序關聯的。
這些名詞有點枯燥，但是在這裡先做解釋可以減少後面我們在解釋 SQL 中可能會出現的誤解。

Keys? 鑰匙?

既然是關聯式資料庫，我們就不能只有一個關聯表，也需要關聯表之間的關係。這時候要能夠連結多個表就需要先定義每個表之間的 "Keys"。這裡的 "Keys" 並不是鑰匙，而是鍵結的「鍵」。延續上面的輕食店，讓我們再加入兩個關聯表:

Customer Table

Review Table

上面那個表示來這間店消費的會員表，我們有三個常客，分別是 Alice，Bob，Chris；下面的表是針對每個品項會員的回饋。
在關聯式資料表中有兩個主要的鍵結，第一種是主鍵 (Primary Key, 簡稱 PK)。我們會說在 Menu Table 中的主鍵是MenuID；Cusomer Table 中的主鍵是CustomerID；Review Table 中的主鍵是ReviewID。有沒有發現，每個關係表一定要存在一個主鍵，這個主鍵不可是空白值也必須要獨一無二，目的是為了要可以「選出」這個關係表中的資料集合。
用更白話文的方式講究是，當有人說 Customer Table 中的 C001 沒有人會不清楚他指的是下面這筆資料集合:

(C001, Alice, F, Gold)

當我們要鏈結兩個資料表的時候，我們就會開始倚賴外來鍵 (Foreign Key, 簡稱 FK)。Review Table 中的 Customer ID 和 Menu ID 就是外來鍵，使得 Review Table 可以鏈結 Customer Table 和 Menu Table。藉這個外來鍵，我們就知道 R001 這筆資料是 Alice (C001) 針對 Lemon Cake (M001) 所寫的回饋。這個外來鍵有一個重要的特徵叫做參考完整性 (Referential Integrity)。在關係表中的外來鍵必須要是存在其他表格中的主鍵。也就是說在上述其他關係表中沒有更變的情況下，不可能存在下面這個 Tuple:

Review(R005, C002, M009, 5, NULL)

因為 M009 並不存在 — 沒有人知道他是什麼。定義 FK 的目的就是讓系統可以避免這種資料被成功輸入一直到 M009 出現在 Menu Table 中。

好了真的寫了很多觀念，明天我們要來動手操作了!