對關系數據庫進行查詢統計時，需要查詢到用戶感興趣的數據，這就需要對關系及關系間進行一定的運算。本篇主要講述關系運算和關系的完整性約束，理解關系操作的含義，了解傳統的集合運算，掌握關系代數中基本關系運算。通過本篇的學習，讀者應該能掌握以下內容：
● 集合的合并、交集、求差、乘積操作
● 關系運算的選擇、投影、連接操作
● 關系的完整性約束
● 關系的范式
關系運算
關系模型是目前用的最多的數據模型，具有嚴格的數學理論基礎，其主要數學理論基礎就是集合運算。關系模型提供了一系列操作的定義，這些操作稱為關系代數操作。它可分為兩類，一類是集合操作；另一類是關系專用的操作。
1、集合操作
集合操作是把關系看作元組的集合來進行傳統的集合運算，其運算結果仍是關系，前提是參與運算的兩個元組具有相同的結構，即含有相同的屬性，且對應屬性的值域相同。下面對傳統的集合運算合并、交集、求差、乘積運算進行逐一說明。
集合運算——合并
假設有A、B兩個集合
A = {1,3,5,9}， B = {2,3,5,7}
由所有屬于集合A或屬于集合B的元素組成的集合，叫做集合A與集合B的合并，也稱為集合A與集合B的并集，記作：
A U B = {1,2,3,5,7,9}
由此可以推出，設R和S是兩個關系，則R U S是合并R和S，合并后的結果仍是關系，結果表中的元組或屬于R，或屬于S，如圖2-10所示：
圖 2-10 集合的合并運算
集合運算——交集
假設有A、B兩個集合
A = {1,3,5,9}， B = {2,3,5,7}
由所有屬于集合A且屬于集合B的元素組成的集合，叫做集合A與集合B的交集，記作：
A n B = {3,5}
由此可以推出，設R和S是兩個關系，則R n S是R和S的交集，求交后的結果仍是關系，結果表中的元組屬于R且屬于S，如圖2-11所示：
圖 2-11 集合的交集運算
集合運算——求差
假設有A、B兩個集合
A = {1,3,5,9}， B = {2,3,5,7}
由所有屬于集合A且不屬于集合B的元素組成的集合，叫做集合A與集合B的差，記作：
A - B = {1,9}
由此可以推出，設R和S是兩個關系，則R - S是求R和S的差，求差后的結果仍是關系，結果表中的元組屬于R且不屬于S，如圖2-12所示：
圖 2-12 集合的求差運算
集合運算——乘積
假設有A、B兩個集合
A = {1,3,5}， B = {2,3}
用A中元素為第一元素，B中元素為第二元素構成有序對，所有這樣的有序對組成的集合叫做A與B的乘積（笛卡爾乘積），記作：
A X B = {(1,2),(1,3),(3,2),(3,3),(5,2),(5,3)}
由此可以推出，設R和S是兩個關系，則R X S是求R和S的笛卡爾乘積，結果表是R和S的結構之連接，即前n個屬性來自R，后m個屬性來自S，屬性個數等于n+m。結果表的值是由R中的每個元組連接S中的每個元組構成元組的集合。如圖2-13所示：
圖 2-13 集合的乘積運算
2、專門的關系運算
專門的關系運算包括選擇、投影、連接和除四種運算。下面介紹常用的三種運算選擇、投影和連接。
選擇運算
選擇運算是單目運算，它從一個關系R中選擇出滿足給定條件的所有元組，并同R具有相同的結構。圖2-14所示為由關系R選出編號為02的老師。
圖 2-14 專門關系運算—選擇運算
投影運算
投影運算也是單目運算，它從一個關系R所有屬性中選擇某些指定屬性，組成一個新的關系。選擇運算選取關系的某些行，而投影運算選取關系的某些列，是從一個關系出發構造其垂直子集的運算。圖2-15所示為由關系R中選出所有老師的姓名和簡介。
圖 2-15 專門關系運算—投影運算
連接運算
連接運算屬于二目運算，是從兩個關系元組的所有組合中選取滿足一定條件的元組，由這些元組形成連接運算的結果關系，其中條件表達式涉及到兩個關系中屬性的比較，該表達式的取值為真或假。圖2-16所示為對課程表和老師表在老師編號相等的條件下進行了連接，在新的關系中僅選出名稱、姓名兩個屬性，即在新關系中再進行一次投影運算，這樣得到了所有老師編號為01的課程名稱和老師姓名。
圖 2-16 專門關系運算—連接運算
關系的完整性
關系模型的完整性主要分為以下四類。
（1）域完整性。關系模型中，每列屬性的取值應是域所確定的值。即屬性的取值范圍應在其值集或值域內。例如在課程表中，名稱屬性值是漢字或英文字符串，所以不能取出數值來，同時，名稱是課程的主要特征，要求必須有課程名稱，即名稱屬性不能為空。
（2）實體完整性。關系模型中每一個表就是一個實體，在現實世界中，實體是可區分的，即它們具有唯一標識。實體映射到關系模型后，每個表也應該具有唯一的標識，這個標識稱為主鍵，用于標識表中唯一的元組。主鍵不能為空，如果主鍵為空，則說明存在某個不可標識的實體，而這和唯一標識相矛盾，即不存在這樣的實體。
（3）參照完整性。實體完整性是一個表內的約束數據庫參照完整性，參照完整性是在不同表之間或同一表的不同元組之間的約束。例如課程表中的老師編號屬性給出了老師的編號，但在課程表中并沒有老師的信息，要想得到老師的信息，就必須通過表中的老師編號到老師表中去查找。由于編號在老師表中是主鍵，這樣能夠找到唯一的一行與該老師編號相對應。對于老師表中的編號屬性來說，通常定義是該表的外關鍵字，簡稱外鍵，同時，編號屬性也是老師表的主鍵。如圖2-17所示：
圖 2-17 老師表與課程表的參照約束
從上圖可以看出，課程表中老師編號屬性的每一個值都能在老師表中找到唯一的一行元組，即能找到唯一的老師與其對應，則稱為參照是完整的，否則，則稱為參照不完整的。
（4）用戶定義的完整性。用戶定義的完整性用于滿足用戶對數據的語義要求，是由用戶對數據庫施加的約束條件。例如，課程視頻長度不能超過30分鐘、老師必須具備專業知識等約束條件。
關系模型的規范化
關系模型的規范化是指面對一個現實問題，如何選擇一個比較好的關系模式集合。
當一個關系模式設計的不夠規范時，就會出現插入異常、刪除異常、冗余過多等問題。例如圖2-18學生選課表中，其中編號、姓名屬性是表的主鍵，在實際應用中，該表會存在插入、刪除、冗余過多等異常。
圖 2-18 學生選課表
（1）插入異常。比如一個剛剛成立的系，但尚未招收學生，則因屬性編號、姓名為空，導致系名、系主任等信息無法存入數據庫；同樣，沒被學生選修的課程也無法存入數據庫。
（2）刪除異常。如一個系的學生畢業了，刪除學生記錄時會將系主任、系名等信息一起刪除。
（3）冗余過多。如一個系的系名、系主任姓名都有與該系學生每門課的成績出現的次數一樣多。既浪費存儲空間又要付出很大的代價來維護數據庫的完整性。當系主任更換后，必須逐一修改該系學生選修課程的每一個元組。
從上面的例子可以看出，一個好的關系模式不應當發生插入異常和刪除異常，且數據冗余盡可能地少。引起數據冗余及其操作異常的原因在于關系的結構。現實世界中的許多事物都可以獨立存在、獨立地被標識、相互間又密切關聯。如果將多個本該是獨立存在地、具有不同標識的事物用一個關系描述，那么不可能找到這樣一個屬性集，它既是這個關系的標識，又是包含在其中的各個不同事物的標識，正是由于關系模式的屬性之間存在過多的數據依賴，從而出現了數據冗余和更新的異常。
數據依賴是指關系中屬性值之間的相互聯系，它是現實世界屬性間相互聯系的體現，是數據之間的內在聯系，是語義的體現。現在人們已經提出了許多種類型的數據依賴，其中最重要的是函數依賴。
函數依賴比較容易理解，且普遍地存在于現實生活中。在學生選課表中，因一個編號僅對應一個學生，一個學生只在一個系注冊學習。因而，當編號的值確定后，姓名和所在系的值也就唯一確定了。當關系模式屬性間存在這個關系時，我們就說姓名和所在系的值依賴于學號，即編號決定姓名和系名。
在學生選課表中除了姓名和系名依賴編號外數據庫參照完整性，還存在其它數據依賴，如一個系只有一個系主任，因此系名依賴于系主任；再如，每個學生學習一門課都有一個成績，因此成績依賴于學號和課程名稱。因為學生選課表中數據依賴過多，導致發生更新異常和數據冗余問題。
解決辦法是將關系模式分解成若干只有單一數據依賴的關系模式，因為關系模式學生選課表出現異常問題是由于屬性之間存在過多的數據依賴造成的，分解的目的就是減少屬性間過多的數據依賴，已期消除關系模式中出現的異常。學生選課表關系模式分解成如圖2-19所示的三個表。
圖 2-19 規范化后的三個關系表
學生選課表規范化后，分解為學生表、成績表、系表三個表，解決了關系模式多數據依賴的問題，每個表都是單一的數據依賴。規范化后雖然解決了數據冗余、更新異常的問題，但檢索效率明顯降低了，需要多表查詢。因此，一個關系是否要進行規范化，應當本著具體問題具體分析的原則進行處理。事實上，如果在一個關系上主要執行的是查詢操作，未必一定要規范化，通過適當地增加一些關系或者在應用程序中注意到更新一致性的維護，非規范化的弊端是可以避免的。但是，如果在關系上要進行頻繁的更新操作，還是要采用規范化的方式比較好。
關系的范式
前面討論了關系模式沒有規范化所引起的異常問題，因此規范化對數據庫設計有著重要的意義。所以建立科學的，規范的數據庫是需要滿足一些約束條件的，在關系型數據庫中這些約束條件被稱為范式。根據一個關系滿足數據依賴程度的不同，人們提出了第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。當然從理論上研究還有其他范式，但實際意義不大，這里不作討論。
（1）第一范式（1NF）。表中所有的屬性都是不可再分的。如學生選課表中系名和系主任就不能合并為一個屬性，因為違反了第一范式。當前所有的關系數據庫都支持第一范式，即要求表屬性都是原子屬性，即屬性的不可分性。
（2）第二范式（2NF）。要求在滿足第一范式的前提下，除去所有不完全依賴于主鍵的屬性（部分依賴）。如學生選課表中，就存在不滿足第二范式的問題，系名和系主任屬性部分依賴于編號屬性（主鍵），因此存在更新異常、數據冗余的問題。第二范式要求所有非主屬性（不屬于主鍵的屬性）都完全依賴于主鍵。
（3）第三范式（3NF）。要求關系在滿足第二范式的前提下，除去所有傳遞依賴于主鍵的屬性，即關系中不含有對主鍵的傳遞依賴。傳遞依賴就是間接依賴。例如在關系R（學號，宿舍，費用）中，費用就間接依賴于學號。