1.2 關系數據庫的基本理論

關系數據庫具有堅實的理論基礎，這一理論有助于關系數據庫的設計和用戶對數據庫信息需求的有效處理。它涉及的內容包括模式的基本知識、關系數據庫的標準語言SQL和關系數據理論，在本節中將對這些內容做簡要的介紹。

1.2.1 數據庫系統與關系數據庫

數據庫系統是指一個計算機存儲記錄的系統，它需要特定的軟件和一系列硬件支持，并且利用數據庫系統能夠存儲大量的數據記錄，支持用戶進行檢索和更新所需的信息。數據庫系統通常在企業應用或科學研究中用于對大量數據進行存儲和分析，從而為實際應用提供幫助。

數據庫系統的硬件設備主要包括：

※ 二級存儲設備，以及相關的I/O設備、設備控制器等：最常用的存儲設備為磁盤，數據庫系統利用存儲設備為數據記錄提供物理存儲空間。

※ 處理器以及相應的內存：足夠快的CPU和足夠大的內存，用于支持數據庫系統軟件的運行。

在物理數據庫（即物理存儲數據的存儲設備）與數據庫用戶之間具有一個中間層，這就是數據庫軟件，通常稱為“數據庫管理系統（DBMS）”。DBMS是建立在操作系統的基礎上的，對物理數據庫進行統一的管理和控制。用戶對數據庫提出的訪問請求都是由DBMS來處理的。DBMS還提供了許多數據操作的實用程序。

DBMS提供的基本功能為數據庫用戶屏蔽了數據庫物理層的細節，使數據庫管理員或者用戶可以以更加高級的方式對物理數據進行管理和操作。另外，DBMS通常也指某個特定廠商的特定產品。例如，Oracle公司的Oracle 11g就是一個非常優秀的DBMS。

實際上，數據庫系統經歷了由層次模型到網狀模型，再由網狀模型到關系模型的發展過程，當今的數據庫大部分都是支持關系模型的關系數據庫。

關系數據庫模型主要由三部分組成。

※ 數據結構：在關系數據庫中，只有一種數據結構—關系。簡單地說，關系就是一張二維表，而關系數據庫就由許多表的集合。

※ 關系操作：關系操作的特點就是集合操作方式，即操作的對象和結果都是集合。

※ 完整性規則：完整性規則用于限制能夠對數據和數據對象進行的關系操作，提供對數據和數據結構的保護。

1.2.2 關系數據庫的邏輯模型

在關系數據庫的設計階段，需要為其建立邏輯模型。關系數據庫的邏輯模型可以通過實體和關系組成的圖來表示，這種圖表稱為E-R圖，使用E-R圖表示的邏輯模型稱為ER模型。一個典型的ER模型由三部分組成—實體、屬性和聯系。

1. 實體和屬性

客觀存在并可相互區分的事物稱為“實體”。實體可以指實際的對象，也可以指某些概念，例如，一個雇員、一個職位都是實體。在E-R模型中，實體用矩形表示，矩形框內寫明實體名，以區分現實世界中的其他對象。

每個實體由一組屬性來表示，其中的某一部分屬性可以唯一標識實例，如雇員編號。實體集是具有相同屬性的實體集合，例如，學校所有教師具有相同的屬性，因此教師的集合可以定義為一個實體集；而學生具有相同的屬性，因此學生的集合可以定義為另一個實體集。

在數據庫中，每個實體集都對應于一個表，實體集中的每個實體都是表中的一條記錄，而實體的每個屬性就是表中的一個字段。例如，企業中的雇員、職位和部門可以分別定義為3個實體集，這些實體集分別對應表EMPLOYEES、JOBS和DEPARTMENTS。每個實體又具有它自己的屬性，這些屬性組成了表的字段。例如，雇員實體具有雇員編號、姓名、電話號碼、職位、薪水、所屬部門等屬性。

2. 聯系

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

※ 一對一：若對于某個實體集A中的每個實體，實體集B中至多有一個實體與之相關；反之亦然，則稱實體集A與實體集B具有一對一的聯系，記為1：1。

※ 一對多：若對于實體集A中的每個實體，實體集B中有多個實體與之相關；反過來，對于實體集B中的每個實體，實體集A中至多有一個實體與之相關，則稱實體集A與實體集B有一對多的聯系，記為1：n。

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

例如，一個雇員只能屬于一個部門，而一個部門可以同時對應于多個雇員，因此，雇員與部門之間具有一對多的聯系，在E-R模型中的表示如下圖所示。

通過邏輯設計，可以將E-R圖表示的邏輯模型轉換為具體DBMS處理的數據模型—關系表。從E-R模型向關系表轉換時，所遵循的規則如下。

※ 每個實體都要轉換成一個關系表，它的屬性為關系表的各個列。

※ 一個1：1的聯系可以轉換為一個關系表，或者與任意一端的關系表合并。若獨立轉換為一個關系表，那么，兩端關系表的鍵及聯系的屬性為該關系表的列；若與一端合并，那么，將另一端的鍵與聯系的屬性合并到該端。

※ 一個1：n聯系可以轉換為一個關系表，或與n端的關系表合并。若獨立轉換為一個關系表，那么，兩端關系表的鍵及聯系的屬性為關系表的列。

※ 對于m：n的聯系可以轉換為一個關系表，兩端關系表的鍵及聯系的屬性為關系表的列，而關系表的鍵為兩端實體的鍵的組合。

例如，在上面的E-R模型中，可以將部門號合并到職工信息表中作為一個列。

1.2.3 關系數據庫的設計規范

在關系數據庫中，為了保證構造的表（關系）既能準確地反應現實世界，又有利于應用和具體的操作，還需要對構造的表進行規范，常用的規范化方法就是對關系應用不同的設計范式。在關系數據庫中，在構建數據庫時必須遵循一定的規則，這種規則就是范式。

關系數據庫中的關系表必須滿足一定的要求，即滿足不同的范式。目前關系數據庫有6種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多要求的稱為第二范式（2NF），其余范式以此類推。一般來說，數據庫只需滿足第三范式（3NF）就足夠了。下面將舉例介紹第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

1. 第一范式（1NF）

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

第一范式（1NF）是指數據庫表中的每一列都是不可分割的基本數據項，同一列中不能有多個值。即實體的某個屬性不能具有多個值，或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。

在第一范式（1NF）中，表的每一行只包含一個實例的信息。例如，對于職工信息表，不能將職工信息都放在一列中顯示，也不能將其中的兩列或多列存入同一列中顯示。職工信息表中每一行只表示一個職工的信息，一個職工的信息在表中只出現一次。

經過第一范式（1NF）后，數據庫表中的字段都是單一的、不可再分的。這個單一屬性由基本數據類型構成，包括整型、實數、字符型、邏輯型、日期型等。例如，下表所示的學生信息表是符合第一范式的。

而下表所示的學生信息表是不符合第一范式的。

很顯然，第一范式是任何關系數據庫管理系統（DBMS）必須滿足的基本條件，任何關系表中各列的數據類型都是基本的數據類型，不允許再進行分隔。

2. 第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實體，或者各個行必須可以被唯一地區分。為實現區分各行，通常需要為表加上一個列，以存儲各個實體的唯一標識。職工信息表中加上了員工編號列，因為每個員工的員工編號是唯一的，因此每個員工可以被唯一區分。這個唯一屬性列稱為主關鍵字或主鍵、主碼。

第二范式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂“完全依賴”，是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分，通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二范式就是非主屬性非部分依賴于主關鍵字。

假定上述學生信息表為表示學生選課信息，以（學號，課程名稱）為組合關鍵字，則存在如下決定關系。

      （學號，課程名稱）→（姓名，聯系電話，年齡，成績，學分）

因為存在如下決定關系，所以這個關系表不滿足第二范式。

     （課程名稱）→（學分）
     （學號）→（姓名，年齡）

即存在組合關鍵字中的部分字段決定非關鍵字的情況。由于不符合2NF，因此這個學生選課關系表會存在如下問題。

※ 數據冗余：若同一門課程可以由n個學生選修，則“學分”重復n次；同樣，若一個學生選修了m門課程，則姓名和年齡等列重復m次。

※ 更新異常：若調整了某門課程的學分，則關系表中所有行的“學分”值都要更新，否則會出現同一門課程，但學分不同的情況。

※ 插入異常：假設要開設一門新的課程，暫時還沒有人選修。這樣，由于沒有“學號”關鍵字，因此課程名稱和學分無法錄入數據庫。

※ 刪除異常：假設一批學生已經完成課程的選修，這些選修記錄就應該從關系表中刪除。但是，與此同時，課程名稱和學分信息也將被刪除。

為克服上述問題，可以把上述關系表改為如下3個表。

※ 學生：Student（學號，姓名，年齡，電話號碼）。

※ 課程：Course（課程名稱，學分）。

※ 選課關系：SelectCourse（學號，課程名稱，成績）。

進行上述分解后，關系表就符合了第二范式，消除了數據冗余、更新異常、插入異常和刪除異常。另外，所有單關鍵字的關系表都符合了第二范式，因為不可能存在組合關鍵字。

3. 第三范式（3NF）

滿足第三范式（3NF）必須先滿足第二范式（2NF）。第三范式要求關系表不存在非關鍵字列對任意候選關鍵字列的傳遞函數依賴。簡而言之，第三范式要求一個關系表中不包含已在其他表中包含的非主關鍵字信息。

所謂“傳遞函數依賴”，就是指如果存在關鍵字x段決定非關鍵字段y，而非關鍵字段y決定非關鍵字段z，則稱非關鍵字段z傳遞函數依賴于關鍵字x。

例如，假定學生關系表Student（學號，姓名，年齡，所在學院，學院地點，學院電話），該關系表的關鍵字為單一關鍵字“學號”，因此存在如下決定關系。

    （學號）→（姓名，年齡，所在學院，學院地點，學院電話）

這個關系表是符合2NF的，但是它不符合3NF，因為存在如下決定關系。

    （學號）→（所在學院）→（學院地點，學院電話）

即存在非關鍵字列“學院地點”和“學院電話”對關鍵字段“學號”的傳遞函數依賴。該關系表也會存在數據冗余、更新異常、插入異常和刪除異常的情況。因此，可以把學生關系表分解為如下兩個表。

※ 學生：Student（學號，姓名，年齡，所在學院）。

※ 學院：Department（學院，地點，電話）。

這樣關系表就符合了第三范式，消除了數據冗余、更新異常、插入異常和刪除異常。

4. BCNF范式

當第三范式消除了主關鍵列對候選關鍵列的部分和傳遞函數依賴，則稱為BCNF。舉例說明，假設倉庫管理關系表（倉庫編號，存儲物品編號，管理員編號，數量），并且規定一個管理員只在一個倉庫工作，一個倉庫可以存儲多種物品。則這個關系表中存在如下決定關系。

     （倉庫編號，存儲物品編號）→（管理員編號，數量）
     （管理員編號，存儲物品編號）→（倉庫編號，數量）

所以，（倉庫編號，存儲物品編號）和（管理員編號，存儲物品編號）都是倉庫管理關系表的候選關鍵列，表中的唯一非關鍵列為“數量”，它是符合第三范式的。但是，由于存在如下決定關系。

     （倉庫編號）→（管理員編號）
     （管理員編號）→（倉庫編號）

即存在關鍵字段決定關鍵字段的情況，所以其不符合BCNF范式。它會出現如下異常情況。

※ 刪除異常：當清空倉庫刪除“存儲物品編號”和“數量”信息時，“倉庫編號”和“管理員編號”信息也將被同時刪除。

※ 插入異常：當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。

※ 更新異常：如果倉庫換了管理員，則表中所有行的管理員編號都要修改。

同樣，可以將倉庫管理關系表分解為兩個關系表。

※ 倉庫管理表：倉庫ID，管理員ID。

※ 倉庫信息表：倉庫ID，存儲物品ID，數量。

這樣創建的關系表就符合了BCNF范式，消除了刪除異常、插入異常和更新異常。