1.2 關系型數據庫的基本理論

視頻講解：光盤\TM\lx\1\基本理論．mp4

數據庫技術是應對信息資源（即大量數據）的管理需求而產生的，隨著信息技術的不斷發展，尤其人類邁入網絡時代后，社會信息資源在爆炸式地增長，對數據管理技術也隨之不斷地提出更高的要求。其先后經歷了人工管理、文件系統、數據庫系統3個階段。在數據庫系統中，數據模型主要有層次模型、網狀模型和關系模型三種（另外一種面向對象模型還處在探索研究中），目前理論成熟、使用普及的模型就是關系模型—關系型數據庫的理論基礎。

1.2.1 關系型數據庫與數據庫管理系統

關系型數據庫是建立在關系模型基礎上的數據庫，借助于集合代數等數學概念和方法來處理數據庫中的數據，現實世界中的各種實體以及實體之間的各種聯系均用關系模型來表示。

關系模型以二維表來描述數據。在關系模型中，每個表有多個字段列和記錄行，每個字段列有固定的類型屬性（如數字、字符、日期等類型）。關系模型數據結構簡單、清晰、具有很高的數據獨立性，因此是目前主流的數據庫數據模型。

在關系數據模型中，關系可以看成由行和列交叉組成的二維表格，表中一行稱為一個元組，可以用來標識實體集中的一個實體。表中的列稱為屬性，給每一列起一個名稱即為屬性名，表中的屬性名不能相同。列的取值范圍稱為域，同列具有相同的域，不同的列也可以有相同的域。表中任意兩行（元組）不能相同。能唯一標識表中不同行的屬性或屬性組（即多個屬性的組合）稱為主鍵或復合主鍵。

盡管關系與傳統的二維表格數據文件具有類似之處，但是它們又有區別，嚴格地說，關系是一種規范化的二維表格，它具有如下性質。

屬性值具有原子性，不可分解。

沒有重復的元組，即沒有重復的行。

理論上沒有行序，但是在使用時有時可以有行序。

在關系型數據庫中，關鍵碼（簡稱鍵）是關系模型的一個非常重要的概念，它通常是行（元組）的一個或幾個列（屬性）。如果鍵是由一個列組成，則稱之為唯一鍵；若是由多個列（屬性）組成的，則稱之為復合鍵，鍵的主要類型如下。

超鍵：在一個關系中，能唯一標識元組的屬性或屬性集稱為關系的超鍵。

候選鍵：如果一個屬性集能唯一標識元組，且又不含有多余的屬性，那么這個屬性集稱為關系的候選鍵。

主鍵：如果一個關系中有多個候選鍵，則選擇其中的一個鍵為關系的主鍵。用主鍵可以實現關系定義中“表中任意兩行（元組）不能相同”的約束。

這里以管理學生信息為例，我們在“學生信息表”中設置學號、姓名、性別、年齡、院系、班級等列。在該表中，“學號”能夠唯一標識一名學生，因此，把學號作為主鍵是最佳的選擇，而如果把“姓名”作為主鍵則會存在問題，因為有可能存在同名的學生。為此，最好創建一個單獨的鍵將其明確地指定為主鍵，這種唯一標識符在現實生活中很普遍，如身份證號、銀行卡號、手機號、發票號等。

外鍵：如果一個關系R中包含另一個關系A的主鍵所對應的屬性組T，則稱此屬性組T為關系R的外鍵，并稱關系A為參照關系，關系R是依賴關系。為了表示關聯，可以將一個關系的主鍵作為屬性放入另外一個關系中，第二個關系中的那些屬性就稱為外鍵。

這里以商品銷售為例，在填寫一張商品銷售單時，可以將商品銷售信息分為兩大類：第一類是單據的主體信息（銷售主表），如銷售單號、銷售金額、銷售日期、收款人；第二類是單據的明細信息（銷售明細表），如商品序號、商品名稱、商品數量等。在數據庫的“銷售主表”中通常以“銷售單號”作為主鍵；在“銷售明細表”中，為了標識被銷售出去的商品隸屬于哪張單據，需要對每一條商品銷售記錄標明“單據編號”。在這種情況下，銷售明細表中的“銷售單號”就被稱為外鍵，因為“銷售單號”是其所在表以外（主體表）的一個主鍵。

當出現外鍵時，主鍵與外鍵的列名稱可以是不同的。但必須要求它們的值集相同，即“銷售明細表”中出現的“銷售單號”一定要和主體表中的值匹配。

對于上面提到的“二維表格”中存儲的數據信息，通常以物理文件的形式存儲在磁盤上，這種物理文件稱為“數據文件”，用戶會使用一種數據庫軟件實現與磁盤上的數據文件進行交互，這種數據庫軟件就稱為數據庫管理系統（英文縮寫為DBMS）。DBMS是建立在操作系統基礎上的，它可以實現對數據庫文件進行統一管理和控制。用戶對數據庫提出的訪問請求都是由DBMS來處理的。另外，DBMS還提供了多種用于管理數據的實用工具。

1.2.2 關系型數據庫的E-R模型

在設計關系型數據庫時，首先需要為它建立邏輯模型。關系型數據庫的邏輯模型可以通過實體和關系組成的圖形來表示，這種圖形稱為E-R圖，它實現將現實世界中的實體和實體之間的聯系轉換為邏輯模型。使用E-R圖形表示的邏輯模型稱為E-R模型，一個標準的E-R模型主要由實體、屬性和聯系3部分組成。

1．實體和屬性

實體是一個數據對象，是指客觀存在并可以相互區分的事物，如一個教師、一個學生、一個雇員等。每個實體由一組屬性來表示，如一個具體的學生擁有學號、姓名、性別和班級等屬性，其中學號可以唯一標識具體某個學生這個實體。具有相同屬性的實體組合在一起就構成實體集—實體的集合，而實體則是實體集中的某一個特例，例如，王同學這個實體就是學生實體集中的一個特例。

在E-R模型中，實體用矩形表示，矩形內注明實體的命名。實體名常用以大寫字母開頭的有具體意義的英文名詞來表示，聯系名和屬性名也采用這種方式。如圖1.2所示為一個圖書檔案的E-R圖。

圖1.2 圖書檔案實體E-R圖

2．聯系

在實際應用中，實體之間是存在聯系的，這種聯系必須在邏輯模型中表現出來。在E-R模型中，聯系用菱形表示，菱形框內寫明“聯系名”，并用“連接線”將有關實體連接起來，同時在“連接線”的旁邊標注上聯系的類型，兩個實體之間的聯系類型可以分為以下3類。

一對一：若對于實體集A中的每一個實體，在實體集合B中最多有一個實體與之相關；反之亦然，則稱實體集A與實體B具有一對一的聯系，可標記聯系為1:1。

一對多：若對于實體集A中的每一個實體，在實體集B中有多個實體與之相關；反之，對于實體集B中的每一個實體，實體集A中最多有一個實體與之相關，則稱實體集A與實體集B具有一對多的聯系，可標記聯系為1:n。

多對多：若對于實體集A中的每一個實體，在實體集B中有多個實體與之相關；反之，對于實體集B中的每一個實體，實體集A中也有多個實體與之相關，則稱實體集A與實體集B具有多對多的聯系，可標記聯系為m:n。

例如，一個讀者可以有多個圖書借還記錄，而一個借還記錄只能隸屬于一個讀者，這樣“讀者檔案實體”與“讀者借還實體”之間就存在一對多的聯系（即1:n），那么這兩個實體之間的聯系如圖1.3所示。

圖1.3 “讀者檔案實體”與“讀者借還實體”之間的聯系

1.2.3 關系型數據庫的設計范式

在數據庫中，數據之間存在著密切的聯系。關系型數據庫由相互聯系的一組關系所組成，每個關系包括關系模式和關系值兩個方面。關系模式是對關系的抽象定義，給出關系的具體結構；關系的值是關系的具體內容，反映關系在某一時刻的狀態。一個關系包含許多元組（記錄行），每個元組都是符合關系模式結構的一個具體值，并且都分屬于相應的屬性。在關系數據庫中的每個關系都需要進行規范化，使之達到一定的規范化程度，從而提高數據的結構化、共享性、一致性和可操作性。

規范化是把數據庫組織成在保持存儲數據完整性的同時最小化冗余數據的結構的過程。規范化的數據庫必須符合關系模型的范式規則。范式可以防止在使用數據庫時出現不一致的數據，并防止數據丟失。關系模型的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）、第六范式（6NF）和BCNF范式等多種。通常數據庫只要滿足前3個范式就足夠用了，下面舉例介紹前3個范式。

1．第一范式（1NF）

第一范式是第二和第三范式的基礎，是最基本的范式。第一范式包括下列指導原則：

數據組的每個屬性只可以包含一個值。

關系中的每個數組必須包含相同數量的值。

關系中的每個數組一定不能相同。

在任何一個關系數據庫中，第一范式是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系型數據庫。

如果數據表中的每一個列都是不可再分割的基本數據項—同一列中不能有多個值，那么就稱此數據表符合第一范式，由此可見第一范式具有不可再分解的原子特性。

在第一范式中，數據表的每一行只包含一個實體的信息，并且每一行的每一列只能存放實體的一個屬性。比如，對于學生信息，不可以將學生實體的所有屬性信息（如學號、姓名、性別、年齡、班級等）都放在一個列中顯示，也不能將學生實體的兩個或多個屬性信息放在一個列中顯示，學生實體的每個屬性信息都放在一個列中顯示。

如果數據表中的列信息都符合第一范式，那么在數據表中的字段都是單一的、不可再分的。如表1.1所示就是不符合第一范式的學生信息表，因為“班級”列中包含了“系別”和“班級”兩個屬性信息，這樣“班級”列中的信息就不是單一的，是可以再分的；而表1.2就是符合第一范式的學生信息表，它將原“班級”列的信息拆分到“系別”列和“班級”列中。

表1.1 不符合第一范式的學生信息表

表1.2 符合第一范式的學生信息表

2．第二范式（2NF）

第二范式（2NF）是在第一范式的基礎上建立起來的，即滿足第二范式（2NF）必先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實體（即各個記錄行）必須可以被唯一地區分。為實現區分各行記錄，通常需要為表設置一個“區分列”，用以存儲各個實體的唯一標識。在學生信息表中，設置了“學號”列，由于每個學生的編號都是唯一的，因此每個學生可以被唯一地區分（即使學生存在重名的情況），那么這個唯一屬性列被稱為主關鍵字或主鍵。

第二范式要求實體的屬性完全依賴于主關鍵字，即不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。

例如，這里以“員工工資信息表”為例，若以（員工編碼、崗位）為組合關鍵字（即復合主鍵），就會存在如下決定關系。

        （員工編碼，崗位）→（決定）（姓名、年齡、學歷、基本工資、績效工資、獎金）

在上面的決定關系中，還可以進一步拆分為如下兩種決定關系。

        （員工編碼）→（決定）（姓名、年齡、學歷）
        （崗位）→（決定）（基本工資）

其中，員工編碼決定了員工的基本信息（包括姓名、年齡、學歷）；而崗位決定了基本工資，所以這個關系表不滿足第二范式。

對于上面的這種關系，可以把上述兩個關系表更改為如下3個表。

員工檔案表：EMPLOYEE（員工編碼、姓名、年齡、學歷）。

崗位工資表：QUARTERS（崗位、基本工資）。

員工工資表：PAY（員工編碼、崗位、績效工資、獎金）。

3．第三范式（3NF）

第三范式（3NF）是在第二范式（2NF）的基礎上建立起來的，即滿足第三范式（3NF）必先滿足第二范式（2NF）。第三范式要求關系表不存在非關鍵字列對任意候選關鍵字列的傳遞函數依賴，也就是說，第三范式要求一個關系表中不包含已在其他表中包含的非主關鍵字信息。

所謂傳遞函數依賴，就是指如果存在關鍵字段A決定非關鍵字段B，而非關鍵字段B決定非關鍵字段C，則稱非關鍵字段C傳遞函數依賴于關鍵字段A。

例如，這里以員工信息表（EMPLOYEE）為例，該表中包含員工編碼、員工姓名、年齡、部門編碼、部門經理等信息，該關系表的關鍵字為“員工編碼”，因此存在如下決定關系：

        （員工編碼）→（決定）（員工姓名、年齡、部門編碼、部門經理）

上面的這個關系表是符合第二范式的，但它不符合第三范式，因為該關系表內部隱含著如下決定關系：

        （員工編碼）→（決定）（部門編碼）→（決定）（部門經理）

上面的關系表存在非關鍵字段“部門經理”對關鍵字段“員工編碼”的傳遞函數依賴。對于上面的這種關系，可以把這個關系表（EMPLOYEE）更改為如下兩個關系表。

員工信息表：EMPLOYEE（員工編碼、員工姓名、年齡、部門編碼）。

部門信息表：DEPARTMENT（部門編碼、部門經理）。

對于關系型數據庫的設計，理想的設計目標是按照“規范化”原則存儲數據，因為這樣做能夠消除數據冗余、更新異常、插入異常和刪除異常。