2.1 關系數據模型

關系模型是由E.F.Codd在1970年提出的一種通用數據模型。由于關系數據模型簡單明了，并且有堅實的數學理論基礎，所以一經推出就受到了業界的高度重視。關系模型被廣泛應用于數據處理和數據存儲，尤其是在數據庫領域，現在主流的數據庫管理系統幾乎都是以關系數據模型為基礎實現的。

2.1.1 關系數據模型中的結構

關系數據模型基于關系這一數學概念。在本小節中，解釋關系數據模型中的術語和相關概念。為了便于說明，我們使用一個分公司-員工關系的例子。假設有一個大型公司在全國都有分公司，每個員工屬于一個分公司，一個分公司有一個經理，分公司經理也是公司員工。分公司-員工關系如圖2-1所示。

1．關系

由行和列構成的二維結構，對應關系數據庫中的表，如示例中的分公司表和員工表。注意，這種認識只是我們從邏輯上看待關系模型的方式，并不應用于表在磁盤上的物理結構。表的物理存儲結構可以是堆文件、索引文件或哈希文件。堆文件是一個無序的數據集合，索引文件中表數據的物理存儲順序和邏輯順序保持一致，哈希文件也稱為直接存取文件，是通過一個預先定義好的哈希函數確定數據的物理存儲位置。

2．屬性

由屬性名稱和類型名稱構成的順序對，對應關系數據庫中表的列，如地址（Variable Characters）是公司表的一個屬性。屬性值是屬性的一個特定的有效值，可以是簡單的標量值，也可以是復合數據類型值。

在關系數據模型中，我們把關系描述為表，表中的行對應不同的記錄，表中的列對應不同的屬性。屬性可以以任何順序出現，而關系保持不變，也就是說，在關系理論中，表中的列是沒有順序的。

3．屬性域

屬性的取值范圍。每一個屬性都有一個預定義的值的范圍。屬性域是關系模型的一個重要特征，關系中的每個屬性都與一個域相關。各個屬性的域可能不同，也可能相同。域描述了屬性所有可能的值。

域的概念是很重要的，因為它允許我們定義屬性可以具有的值的意義。系統可因此獲得更多的信息，并且可以拒絕不合理的操作。在我們的例子中，分公司編號和員工編號都是字符串，但顯然具有不同的含義，換句話說，它們的屬性域是不同的。表2-1列出了分公司-員工關系的一些屬性域。

4．元組

關系中的一條記錄，對應關系數據庫中的一個表行。元組可以以任何順序出現，而關系保持不變，也就是說，在關系理論中，表中的行是沒有順序的。

5．關系數據庫

一系列規范化的表的集合。這里的規范化可以理解為表結構的正確性。本節后面會詳細討論規范化問題。

以上介紹了關系數據模型的兩組術語：“關系、屬性、元組”和“表、列、行”。在這里它們的含義是相同的，只不過前者是關系數據模型的正式術語，而后者是常用的數據庫術語。其他可能會遇到的類似術語還有實體（表）、記錄（行）、字段（列）等。

6．關系表的屬性

關系表有如下屬性：

● 每個表都有唯一的名稱。

● 一個表中每個列有不同的名字。

● 一個列的值來自于相同的屬性域。

● 列是無序的。

● 行是無序的。

7．關系數據模型中的鍵

（1）超鍵

一個列或者列集，唯一標識表中的一條記錄。超鍵可能包含用于唯一標識記錄所不必要的額外的列，我們通常只對僅包含能夠唯一標識記錄的最小數量的列感興趣。

（2）候選鍵

僅包含唯一標識記錄所必需的最小數量列的超鍵。表的候選鍵有三個屬性：

● 唯一性：在每條記錄中，候選鍵的值唯一標識該記錄。

● 最小性：具有唯一性屬性的超鍵的最小子集。

● 非空性：候選鍵的值不允許為空。

在我們的例子中，分公司編號是候選鍵，如果每個分公司的郵編都不同，那么郵編也可以作為分公司表的候選鍵。一個表中允許有多個候選鍵。

（3）主鍵

唯一標識表中記錄的候選鍵。主鍵是唯一、非空的。沒有被選做主鍵的候選鍵稱為備用鍵。對于例子中的分公司表，分公司編號是主鍵，郵編就是備用鍵，而員工表的主鍵是員工編號。

主鍵的選擇在關系數據模型中非常重要，很多性能問題都是由于主鍵選擇不當引起的。在選擇主鍵時，我們可以參考以下原則：

● 主鍵要盡可能地小。

● 主鍵值不應該被改變。主鍵會被其他表所引用。如果改變了主鍵的值，所有引用該主鍵的值都需要修改，否則引用就是無效的。

● 主鍵通常使用數字類型。數字類型的主鍵要比其他數據類型效率更高。

● 主鍵應該是沒有業務含義的，它不應包含實際的業務信息。無意義的數字列不需要修改，因此是主鍵的理想選擇。大部分關系型數據庫支持的自增屬性或序列對象更適合當作主鍵。

● 雖然主鍵允許由多列組成，但應該使用盡可能少的列，最好是單列。

（4）外鍵

一個表中的一個列或多個列的集合，這些列匹配某些其他（也可以是同一個）表中的候選鍵。注意外鍵所引用的不一定是主鍵，但一定是候選鍵。當一列出現在兩張表中的時候，它通常代表兩張表記錄之間的關系。如例子中分公司表的分公司編號和員工表的所屬分公司。它們的名字雖然不同，但卻是同一含義。分公司表的分公司編號是主鍵，在員工表里所屬分公司是外鍵。同樣，因為公司經理也是公司員工，所以它是引用員工表的外鍵。主鍵所在的表被稱為父表，外鍵所在的表被稱為子表。

2.1.2 關系完整性

上一小節討論了關系數據模型的結構部分，本小節討論關系完整性規則。關系數據模型有兩個重要的完整性規則：實體完整性和參照完整性。在定義這些術語之前，先要理解空值的概念。

1．空值（NULL）

表示一個列的值目前還不知道或者對于當前記錄來說不可用。空值可以意味著未知，也可以意味著某個記錄沒有值，或者只是意味著該值還沒有提供。空值是處理不完整數據或異常數據的一種方式。空值與數字零或者空字符串不同，零和空字符串是值，但空值代表沒有值。因此，空值應該與其他值區別對待。空值具有特殊性，當它參與邏輯運算時，結果取決于真值表。每種數據庫系統對空值參與運算的規則定義也不盡相同。表2-2到表2-4分別是Oracle的非、與、或邏輯運算真值表。

在我們的例子中，如果一個分公司的經理離職了，新的經理還沒有上任，此時公司經理列對應的值就是空值。

2．關系完整性規則

有了空值的定義，就可以定義兩種關系完整性規則了。

（1）實體完整性

在一個基本表中，主鍵列的取值不能為空。基本表指的是命名的表，其中的記錄物理地存儲在數據庫中，與之對應的是視圖。視圖是虛擬的表，它只是一個查詢語句的邏輯定義，其中并沒有物理存儲數據。

從前面介紹的定義可知，主鍵是用于唯一標識記錄的最小列集合。也就是說，主鍵的任何子集都不能提供記錄的唯一標識。空值代表未知，無法進行比較。如果允許空值作為主鍵的一部分，就意味著并不是所有的列都用來區分記錄，這與主鍵的定義矛盾，因此主鍵必須是非空的。例如，分公司編號是分公司表的主鍵，在錄入數據的時候，該列的值不能為空。

（2）參照完整性

如果表中存在外鍵，則外鍵值必須與主表中的某些記錄的候選鍵值相同，或者外鍵的值必須全部為空。在圖2-1中，員工表中的所屬分公司是外鍵。該列的值要么是分公司表的分公司編號列中的值，要么是空（如新員工已經加入了公司，但還沒有被分派到某個具體的分公司時）。

3．業務規則

定義或約束組織的某些方面的規則。業務規則的例子包括屬性域和關系完整性規則。屬性域用于約束特定列能夠取的值。有些數據庫系統，如Oracle，支持叫做check的約束，也用于定義列中可以接受的值，但這種約束是定義在屬性域之上的，比屬性域的約束性更強。例如，員工表的性別列就可以加上check約束，使它只能取有限的幾個值。

4．關系數據庫語言

關系語言定義了允許對數據進行的操作，包括從數據庫中更新或檢索數據所用的操作以及改變數據庫對象結構的操作。關系數據庫的主要語言是SQL語言。

SQL是Structured Query Language的縮寫，意為結構化查詢語言。SQL已經被國際標準化組織（ISO）進行了標準化，使它成為正式的和事實上的定義和操縱關系數據庫的標準語言。SQL語言又可分為DDL、DML、DCL、TCL四類。

DDL是Data Definition Language的縮寫，意為數據定義語言，用于定義數據庫結構和模式。典型的DDL有create、alter、drop、truncate、comment、rename等。

DML是Data Manipulation Language的縮寫，意為數據操縱語言，用于檢索、管理和維護數據庫對象。典型的DML有select、insert、update、delete、merge、call、explain、lock等。

DCL是Data Control Language的縮寫，意為數據控制語言，用于授予和回收數據庫對象上的權限。典型的DCL有grant和revoke。

TCL是Transaction Control Language的縮寫，意為事務控制語言，用于管理DML對數據的改變。它允許一組DML語句聯合成一個邏輯事務。典型的TCL有commit、rollback、savepoint、set transaction等。

2.1.3 規范化

關系數據模型的規范化是一種組織數據的技術。規范化方法對表進行分解，以消除數據冗余，避免異常更新，提高數據完整性。

不規范化帶來的問題

沒有規范化，數據的更新處理將變得困難，異常的插入、修改、刪除數據的操作會頻繁發生。為了便于理解，來看下面的例子。

假設有一個名為employee的員工表，它有九個屬性：id（員工編號）、name（員工姓名）, mobile（電話）、zip（郵編）、province（省份）、city（城市）、district（區縣）、deptNo（所屬部門編號）、deptName（所屬部門名稱），表中的數據如表2-5所示。

由于此員工表是非規范化的，我們將面對如下的問題。

修改異常：上表中張三有兩條記錄，因為他隸屬兩個部門。如果我們要修改張三的地址，必須修改兩行記錄。假如一個部門得到了張三的新地址并進行了更新，而另一個部門沒有，那么此時張三在表中會存在兩個不同的地址，導致了數據不一致。

新增異常：假如一個新員工加入公司，他正處于入職培訓階段，還沒有被正式分配到某個部門，如果deptNo字段不允許為空，我們就無法向employee表中新增該員工的數據。

刪除異常：假設公司撤銷了D3這個部門，那么在刪除deptNo為D3的行時，會將李四的信息也一并刪除。因為他只隸屬于D3這一個部門。

為了克服這些異常更新，我們需要對表進行規范化設計。規范化是通過應用范式規則實現的。最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。

（1）第一范式（1NF）

表中的列只能含有原子性（不可再分）的值。

上例中張三有兩個手機號存儲在mobile列中，違反了1NF規則。為了使表滿足1NF，數據應該修改為如表2-6所示。

（2）第二范式（2NF）

第二范式要同時滿足下面兩個條件：

● 滿足第一范式。

● 沒有部分依賴。

例如，員工表的一個候選鍵是{id, mobile, deptNo}，而deptName依賴于{deptNo}，同樣name僅依賴于{id}，因此不是2NF的。為了滿足第二范式的條件，需要將這個表拆分成employee、dept、employee_dept、employee_mobile四個表，如表2-7至表2-10所示。

（3）第三范式（3NF）

第三范式要同時滿足下面兩個條件：

● 滿足第二范式。

● 沒有傳遞依賴。

例如，員工表的province、city、district依賴于zip，而zip依賴于{id}，換句話說，province、city、district傳遞依賴于{id}，違反了3NF規則。為了滿足第三范式的條件，可以將這個表拆分成employee和zip兩個表，如表2-11、表2-12所示。

在關系數據模型設計中，一般需要滿足第三范式的要求。如果一個表有良好的主外鍵設計，就應該是滿足3NF的表。規范化帶來的好處是通過減少數據冗余提高更新數據的效率，同時保證數據完整性。然而，我們在實際應用中也要防止過度規范化的問題。規范化程度越高，劃分的表就越多，在查詢數據時越有可能使用表連接操作。而如果連接的表過多，會影響查詢的性能。關鍵的問題是要依據業務需求，仔細權衡數據查詢和數據更新的關系，制定最適合的規范化程度。還有一點需要注意的是，不要為了遵循嚴格的規范化規則而修改業務需求。

2.1.4 關系數據模型與數據倉庫

關系數據模型可以提供高性能的數據更新操作，能很好地滿足事務型系統的需求，這點毋庸置疑。但是對于查詢與分析密集型的數據倉庫系統還是否合適呢？對這個問題的爭論由來已久，基本可以分為Inmon和Kimball兩大陣營，Inmon陣營是應用關系數據模型構建數據倉庫的支持者。

Inmon方法是以下面這些假設的成立為前提的。

● 假設數據倉庫是以企業為中心的，初始的數據能夠為所有部門所使用。而最終的數據分析能力是在部門級別體現，需要使用數據集市對數據倉庫中的數據做進一步處理，以便為特定的部門定制它們。

● 數據倉庫中的數據不違反組織制定的任何業務規則。

● 必須盡可能快地把新數據裝載進數據倉庫，這意味著需要簡化數據裝載過程或減少數據的裝載量。

● 數據倉庫的建立必須從一開始就被設計成支持多種BI技術，這就要求數據倉庫本身所使用的技術越通用越好。

● 假設數據倉庫的需求一定會發生變化。它必須能完美地適應其數據和數據結構的變化。

基于這些假設，使用關系數據模型構建數據倉庫的優勢和必然性就比較明顯了。

1．非冗余性

為適應數據倉庫有限的裝載周期和海量數據，數據倉庫數據模型應該包含最少量的數據冗余。冗余越少，需要裝載的數據量就越少，裝載過程就越快。另外，數據倉庫的數據源一般是事務型系統，這些系統通常是規范化設計的。如果數據倉庫使用相同的數據模型，意味著數據轉換的復雜性可能會降低，同樣可以加快數據裝載速度。

2．穩定性

由于數據倉庫的需求會不斷變化，我們需要以一種迭代的方式建立數據倉庫。眾所周知，組織中最經常變化的是它的處理過程、應用和技術，如果依賴于這三個因素中的任何一個建立數據模型，當它們發生改變時，肯定要對數據模型進行徹底修改。為了避免這個問題，關系數據模型的通用性正是用武之地。另一方面，由于變化不可避免，數據倉庫模型應該能比較容易地將新的變化合并進來，而不必重新設計已有的元素和已經實現的實體。

3．一致性

數據倉庫模型最本質的特點是保證作為組織最重要資源的數據的一致性，而確保數據一致性正是關系數據模型的特點之一。

4．靈活性

數據倉庫最重要的一個用途是作為堅實的、可靠的、一致的數據基礎為后續的報表系統、數據分析、數據挖掘或BI系統服務。數據模型還必須支持為組織建立的業務規則。這就意味著數據模型必須比簡單的平面文件功能更強。為此關系數據模型也是最佳選擇之一。

關系數據模型已被證明是可靠的、簡單的數據建模方法。應用其規范化規則，將產生一個穩定的、一致的數據模型。該模型支持由組織制定的政策和約定的規則，同時為數據集市分析數據提供了更多的靈活性，使得數據庫存儲以及數據裝載方面也是最有效的。

當然，任何一種數據模型都不可能是完美無瑕的。關系數據模型的缺點也很明顯，它需要額外建立數據集市的存儲區，并增加相應的數據裝載過程。另外，對數據倉庫的使用強烈依賴于對SQL語言的掌握程度。