第2章關系數據庫主要內容2.1關系模型2.2關系代數2.3關系數據庫設計2.4本章小結2.1關系模型E.F.Codd,1970關系模型的三要素關系數據結構關系數據操作關系的完整性約束條件2.1.1關系模型的三要素關系數據結構關系模型的數據結構非常單一，即關系。現實世界中的實體以及實體之間的各種聯系統一用關系表示。在用戶看來，一個關系就是一張二維表。行：元組（記錄）列：屬性（字段）2.1.1關系模型的三要素關系數據操作查詢和更新（插入、修改、刪除）兩大類集合操作方式（set-at-a-time）高度非過程化種類2.1.1關系模型的三要素關系的完整性約束條件實體完整性參照完整性用戶定義的完整性實體完整性和參照完整性是關系模型必須滿足的完整性約束條件，被稱為關系的兩個不變性，應由關系系統自動支持。具體的應用領域還可能存在一些特定的語義約束，用戶可以相應地定義一些完整性約束條件，這些完整性約束條件一經用戶定義也應由關系系統自動支持。2.1.2關系數據結構域（Domain）一組具有相同數據類型的值的集合。在關系中，域用來作為屬性的取值范圍。學號屬性所取的由11位數字組成的字符串集合年齡屬性所取的大于14且小于40的正整數集合性別屬性所取的由“男”和“女”這兩個值組成的集合笛卡爾積（CartesianProduct）給定了一組域，這些域的笛卡爾積定義為：每一個元素稱為一個n-元組（n-tuple），簡稱元組（Tuple）。元組中的每一個值稱為一個分量（Component）。2.1.2關系數據結構若干域的笛卡爾積可表示成一張二維表，表中的每一行對應于笛卡爾積的每一個元素或元組，表中的每一列對應于笛卡爾積的每一個域。例如，給定了以下三個域：姓名集合(name)={張林，李宏}年齡集合(age)={20，21}專業集合(major)={計算機科學與技術，軟件工程}則它們的笛卡爾積為：

{(張林，20，計算機科學與技術)，(張林，20，軟件工程)，(張林，21，計算機科學與技術)，(張林，21，軟件工程)，(李宏，20，計算機科學與技術)，(李宏，20，軟件工程)，(李宏，21，計算機科學與技術)，(李宏，21，軟件工程)}2.1.2關系數據結構該笛卡爾積一共有

個元組，可表示成如表2.1所示的一張二維表。顯然，如表2.1所示的笛卡爾積中有很多元組是沒有任何實際意義的。2.1.2關系數據結構關系（Relation）從相關域的笛卡爾積中抽取的具有實際意義的若干元組所構成的集合。作為笛卡爾積的子集，關系同樣可以表示成二維表的形式。假設所有學生都不會同名，且每名學生只屬于一個專業，那么表2.1中只有兩個元組具有實際意義。假設張林和李宏的年齡分別是21和20歲，分別是計算機科學與技術和軟件工程專業的學生，相應的兩個元組就構成了描述學生年齡及其所屬專業的一個關系，如表2.2所示。2.1.2關系數據結構關系（Relation）關系的每一行就是關系的一個元素或元組（Tuple），描述一個具體的實體或實體之間的一個具體聯系，通常用t表示。關系的每一列就是關系的一個屬性（Attribute）或字段（Field），其值來自相應的域。在關系的所有屬性中，可以唯一確定一個元組的屬性或屬性的最小組合稱為該關系的碼（鍵，Key）或候選碼（候選鍵，CandidateKey）。如果候選碼多于一個，則選取其中一個候選碼作為主碼（主鍵，PrimaryKey）。包含在任一候選碼中的屬性稱為主屬性（PrimaryAttribute）。不包含在任何候選碼中的屬性稱為非主屬性（Non-PrimaryAttribute）或非碼屬性（Non-KeyAttribute）。2.1.2關系數據結構關系（Relation）關系模型要求關系必須是規范的，即要求關系必須滿足一定的規范性條件，滿足一定規范性條件的關系模式的集合稱為范式（NormalForm，簡稱NF）。最基本的規范條件就是關系的每一個分量都必須取不可再分的原子值。2.1.2關系數據結構關系模式（RelationSchema）對關系的結構及其特征的抽象描述，相對穩定。形式化表示為一個五元組R(U,D,dom,F)R為關系名。U為組成該關系的屬性名集合。D為U中各屬性來自的域集合。dom為屬性到域的映射集合，用來確定U中的每一個屬性分別來自D中的哪一個域。F為屬性間的數據依賴集合，用來限定組成該關系的各元組必須滿足的完整性約束條件，體現了關系的元組語義。通常簡記為：R(U)或R

(A1,A2,…,An)表2.2中的student關系可抽象描述為：student(name,age,major)關系模式與關系：型（Type）與值（Value）2.1.3關系的完整性約束條件實體完整性（EntityIntegrity）

若屬性A是關系R的主屬性，則屬性A不能取空值。所謂空值（null）是指“不知道”或“不存在”的值。由于主屬性是用來唯一標識實體的基本屬性，若主屬性取空值，就說明這個實體不能被唯一標識，這與現實世界的要求和實體能被相互區分是背離的。實體完整性要求所有主屬性都不能取空值。student(name,age,major)選修（學號，課程號，成績）2.1.3關系的完整性約束條件參照完整性（ReferentialIntegrity）現實世界中實體與實體之間往往存在著某種聯系，表現在關系數據庫中就是關系與關系之間的屬性引用。學生、專業實體以及它們之間的一對多的屬于聯系可以用下面兩個關系表示：學生（學號，姓名，性別，年齡，專業號）專業（專業號，專業名，專業負責人）學生和專業之間的屬于聯系表現為這兩個關系之間的屬性引用，即學生關系的“專業號”屬性引用了專業關系的主碼“專業號”。2.1.3關系的完整性約束條件參照完整性（ReferentialIntegrity）學生關系中的“專業號”值必須是確實存在的某個專業的專業號，即專業關系中的某個“專業號”值，專業關系中不存在的“專業號”值是毫無意義的。在這樣的屬性引用中，學生關系中“專業號”屬性的取值需要參照專業關系中主碼“專業號”的取值。2.1.3關系的完整性約束條件參照完整性（ReferentialIntegrity）在學生關系中，“專業號”屬性雖然不是主碼，但它卻引用（或參照）了專業關系的主碼，這樣的屬性引用不但可以表達學生和專業之間的屬于聯系，而且還使它的取值受到了一定的限制，這樣的屬性稱為外碼或外鍵。外碼：設F是關系R的一個（或一組）屬性，但不是關系R的碼，若F引用（或參照）了關系S的主碼Ks，則稱F是R的外碼（外鍵，ForeignKey）。顯然，外碼F和主碼Ks必須定義在同一個（或同一組）域上。2.1.3關系的完整性約束條件參照完整性（ReferentialIntegrity）參照完整性：若屬性（或屬性組）F是關系R的外碼，引用（或參照）的是關系S的主碼Ks，則R中每個元組在F上的取值要么為空值；要么為S中某個元組的Ks值。和實體完整性約束主屬性的取值不同，參照完整性約束的是外碼的取值，用來保證外碼對相應主碼的正確引用，以體現客觀對象之間的各種聯系，從而實現了數據的整體結構。級聯刪除級聯修改按照參照完整性，學生關系中的“專業號”屬性要么取空值，表示該生尚未分配專業或者不知道他的專業；要么取專業關系中的某個“專業號”值，表示該生已屬于某個確實存在的專業。2.1.3關系的完整性約束條件參照完整性（ReferentialIntegrity）學生（學號，姓名，性別，年齡，專業號）課程（課程號，課程名，學分）選修（學號，課程號，成績）選修關系和學生、課程關系之間都存在屬性的引用。因此，選修關系有兩個外碼：學號和課程號。2.1.3關系的完整性約束條件參照完整性（ReferentialIntegrity）按照參照完整性選修關系的“學號”屬性要么取空值，要么取學生關系中的某個“學號”值，即某名學生的學號。選修關系的“課程號”屬性要么取空值，要么取課程關系中的某個“課程號”值，即某門課程的課程號。當然，這兩個屬性都不能取空值。為什么？2.1.3關系的完整性約束條件用戶定義的完整性（User-definedIntegrity）除了實體完整性和參照完整性外，具體的應用領域還可能存在一些特定的語義約束。大學生的年齡限定在14~40歲之間課程名要求不重復大學生的不及格門次限定在3門以下成績的取值范圍為0~100…

…為了使數據能正確反映這些語義約束，從而真實地模擬現實世界，用戶可以相應地定義一些完整性約束條件。這些完整性約束條件一經用戶定義，也應和實體完整性、參照完整性一樣由關系系統自動支持，而不應像文件系統那樣由應用程序來承擔這一功能。2.2關系代數用對關系的運算即代數方式來表達查詢的一種抽象的查詢語言。運算對象是一個或多個關系運算結果也是一個新的關系運算符：8個2.2.1傳統的集合運算并（Union）

交（Intersection）

差（Difference）

很顯然，條件：R和S具有相同的屬性個數，并且對應的屬性來自同一個域，即它們的結構是兼容的。RS2.2.1傳統的集合運算假設由所有2019級學生構成的關系為student_2019（如表2.5所示），由所有獲得一等獎學金的學生構成的關系為student_first（如表2.6所示）。2.2.1傳統的集合運算廣義笛卡爾積（ExtendedCartesianProduct）

表示R中元組

和S中元組

拼接而成的一個新元組。2.2.2專門的關系運算選擇（Selection）又稱限制（Restriction），是一個單目運算，其結果是從參與運算的關系中選擇滿足給定條件的那些元組所構成的一個新關系。F為選擇條件，是由邏輯運算符∧（and）、∨（or）或﹁（not）連接各比較表達式組成的一個邏輯表達式。就是從關系R中選擇使條件F為真的那些元組。2.2.2專門的關系運算假設學生選課數據庫包括學生關系、課程關系和選修關系。2.2.2專門的關系運算【例2-1】查詢0101號專業所有學生的基本情況。

或2.2.2專門的關系運算【例2-2】查詢年齡小于或等于20歲的0101號專業所有學生的基本情況。

或

2.2.2專門的關系運算投影（Projection）單目運算，其結果是從參與運算的關系中選擇給定的若干屬性所構成的一個新關系。A為R中的屬性（或屬性組）。和選擇操作不同，投影操作是從屬性（列）的角度進行運算。【例2-3】查詢所有學生的學號和姓名。

或2.2.2專門的關系運算【例2-4】查詢學生表中有哪些專業。

或由于只保留了關系的部分列，因此可能會出現重復行，投影結果應消除這些重復行，如表2.19所示。

2.2.2專門的關系運算連接（Join）廣義笛卡爾積會產生大量無效元組，為了避免出現無效元組，只有滿足一定條件才允許將對應的元組進行拼接，這就是連接操作。連接，也稱連接，是從兩個關系的廣義笛卡爾積中選擇屬性間滿足一定條件的元組所構成的一個新關系。或者說，兩個關系的元組只有相應分量的取值滿足一定條件時才能拼接成為新關系中的元組。其中，A和B分別為R和S中可比較的屬性（組），是比較運算符。R中元組在屬性（組）A上的取值和S中元組在屬性（組）B上的取值只有滿足條件時才能拼接成為中的元組。2.2.2專門的關系運算兩種最常用的連接等值連接（Equi-Join）

自然連接（NaturalJoin）

自然連接是一種特殊的等值連接。自然連接要求兩個關系中進行等值比較的屬性（組）必須是相同的屬性（組）。自然連接的結果要把重復的屬性去掉。2.2.2專門的關系運算【例2-5】設有如圖2.4(a)和圖2.4(b)所示的兩個關系R和S，則不同連接的結果分別如圖2.4(c)~圖2.4(e)所示。2.2.2專門的關系運算【例2-6】查詢選修了課程的學生及其選修課程的基本情況。

2.2.2專門的關系運算除（Division）若要查詢選修了某些課程的學生，并且這些課程不能明確地一一列舉出來，而只是滿足了給定特征（或具有了相同性質）的一組課程，如“劉麗”選修的全部課程，這種情況下僅用選擇操作是遠遠不夠的，因為選擇條件無法明確給出，這時可以用除運算。給定關系R(X,Y)和S(Y,Z)，即R和S具有相同的屬性（組）Y，R與S的除運算得到一個新關系P(X)，P是R中滿足以下條件的元組在屬性（組）X上的投影：元組在X上的取值x對應的Y值集合（記作x映射到Y上的象集Yx）包含S在Y上投影的集合。

2.2.2專門的關系運算【例2-7】查詢至少選修了101和202兩門課程的學生學號。若要用選擇運算，需要用到集合的交運算，即有：若要用除運算，需要先將查詢條件中的不同課程號組建為一個臨時關系（集合）K：

×2.2.3綜合實例【例2-8】查詢選修了“數據結構”課程的學生學號。解法一：解法二：選擇哪個？2.2.3綜合實例【例2-9】查詢選修了全部課程的學生學號和姓名。【例2-10】查詢沒有選修202號課程的學生學號。×數據庫設計是針對一個具體的應用環境，設計優化的數據庫邏輯結構和物理結構，并據此建立數據庫及其應用系統，使之能夠有效地存儲、管理和利用數據，滿足各種用戶的應用需求（包括數據需求、處理需求、安全性和完整性需求等）。數據庫設計不但要建立數據庫，而且還要建立基于數據庫的應用系統，即設計整個數據庫應用系統，這是對數據庫設計的廣義理解。本書主要討論狹義的數據庫設計，即設計數據庫本身，或者說，設計數據庫的各級模式并據此建立數據庫。2.3關系數據庫設計2.3關系數據庫設計結構（數據）設計和行為（處理）設計相結合數據庫中存儲什么樣的數據以及它們以什么樣的結構組織在一起決定了應用系統能夠實現哪些功能以及它們的執行效率如何。具體應用需求還能用來對數據庫的結構進行有針對性的優化。為提高登錄操作的執行效率（它對用戶的滿意度影響很大），可以把該操作涉及到的用戶名和密碼這2個屬性從用戶表中分解出來單獨建表。為經常放在一起查詢的不同表中的屬性考慮是否能將其合并并存儲在同一個節點上。為經常出現在查詢條件中的屬性建立索引。2.3.1數據庫設計的步驟按照規范設計法，目前人們通常把數據庫設計的全過程分為以下6個基本階段：需求分析概念結構設計邏輯結構設計物理結構設計數據庫實施數據庫運行和維護在這六個階段中，需求分析和概念結構設計可以獨立于任何數據庫管理系統，因此，在設計的初期，并不急于確定到底采用哪一種數據庫管理系統，從邏輯結構設計階段開始才需要選擇一種具體的數據庫管理系統。2.3.1數據庫設計的步驟數據庫的設計需要多種人員在不同階段參與進來，包括系統分析人員、數據庫設計人員、數據庫管理員、應用開發人員和用戶。系統分析人員和數據庫設計人員是數據庫設計的核心人員，他們將自始至終參與數據庫的設計，他們的水平直接決定了數據庫系統的質量。由于需要對數據庫進行全面的管理、控制和維護，數據庫管理員也需要參與數據庫設計的全過程。應用開發人員（包括程序員和操作員）在數據庫實施階段參與進來，負責編制程序和準備軟硬件環境。用戶在需求分析階段和概念結構設計階段參與進來，使設計人員能準確把握用戶的各種需求，并設計出用戶認可的概念模型；此外，設計出來的數據庫最終還要交給用戶正式運行，因此，用戶還要參與數據庫的運行和維護階段。2.3.1數據庫設計的步驟需求分析階段進行數據庫設計首先必須準確了解和分析各種用戶的應用需求。需求分析是整個設計過程的基礎和起點，需求分析做得是否充分與準確，決定了在此基礎上建立的數據庫能否有效地實現既定目標。通過調查、搜集和分析，獲得用戶對數據庫的以下需求：數據需求處理需求安全性與完整性需求對用戶的以上需求進行分析和表達之后，必須提交給用戶，征得用戶的認可。需求分析階段的一個重要而困難的任務是搜集將來應用可能涉及到的數據，設計人員應充分考慮到應用的可擴充性，使系統易于擴充。2.3.1數據庫設計的步驟概念結構設計階段概念結構設計是整個數據庫設計的關鍵，它通過對用戶需求進行綜合、歸納和抽象，形成獨立于任何數據庫管理系統的概念模型，通常用E-R圖表達。在需求分析階段得到的應用需求首先應抽象為信息世界中的概念模型，這樣才能更準確地用某一數據庫管理系統支持的數據模型來實現這些需求。和數據模型相比，概念模型更容易被用戶理解，能讓用戶積極地參與到數據庫設計中來，是數據庫設計成功的關鍵。2.3.1數據庫設計的步驟邏輯結構設計階段邏輯結構設計是將概念模型轉換為某一數據庫管理系統支持的數據模型（如關系模型），并對其進行優化。除模式外，邏輯結構設計還要根據用戶對數據的不同需求建立必要的視圖，即外模式。2.3.1數據庫設計的步驟物理結構設計階段物理結構設計是為數據模型選取一個最適合應用環境的物理結構，包括存儲結構和存取方法，這依賴于具體的數據庫管理系統。不同的數據庫管理系統提供的物理環境、存取方法和存儲結構有很大差別，為此，需要對在數據庫上運行的各種事務進行詳細分析，根據所用數據庫管理系統提供的存儲結構和存取方法，選取一個最適合應用環境的物理結構，使得在數據庫上運行的各種事務的總體（或期望）響應時間小、存儲空間利用率高、事務吞吐率大。2.3.1數據庫設計的步驟物理結構設計階段為了提高數據的存取效率可以為某些屬性（如用于表連接的屬性、經常出現在查詢條件中的屬性以及經常需要排序的屬性等）建立必要的索引。可以通過分區、條帶化存儲、冗余存儲等機制利用并行處理技術來提高數據的存取效率。根據實際情況將數據的易變部分和穩定部分、經常存取部分和存取頻率較低部分分開存放。在物理結構設計過程中，需要對時間效率、空間效率和維護代價這3個方面的因素進行權衡（它們常常是相互矛盾的），可以產生多種方案，數據庫設計人員應對其進行細致的評價，從中選取一個較優的方案作為數據庫的物理結構。2.3.1數據庫設計的步驟數據庫實施階段根據邏輯結構設計和物理結構設計的結果，開發人員使用數據庫管理系統提供的數據定義語言（如SQL中的CREATE命令）建立數據庫，并編制、調試應用程序，組織數據入庫，進行試運行。在協商一致的前提下，分期分批地組織數據入庫，逐步增加數據量，逐步完成運行評價。在試運行階段，首先應調試運行數據庫管理系統的轉儲和恢復功能，做好數據庫的轉儲和恢復工作，盡量減少故障對數據庫的破壞。2.3.1數據庫設計的步驟數據庫運行和維護階段數據庫試運行合格后，就可以交付給用戶正式運行了。由于應用環境的不斷變化，對數據庫的維護工作將是一項長期任務。在數據庫運行階段，對數據庫經常性的維護工作主要由數據庫管理員負責完成，包括以下內容：數據庫的轉儲和恢復數據的安全性和完整性控制數據庫性能的監督、分析與改造數據庫的重組織和重構造設計一個完善的數據庫應用系統往往需要以上6個階段的不斷反復。2.3.1數據庫設計的步驟2.3.2概念結構設計概念結構設計是將用戶需求抽象為概念模型（或稱概念結構）的過程，是整個數據庫設計的關鍵。從客觀世界中抽取系統需要記錄的眾多實體（進一步抽象為實體型）及其聯系，然后以用戶容易理解的格式（如E-R圖）表達出來，以便征得用戶的認可。依托E-R圖進行數據庫設計的方法就是人們常用的基于E-R圖的數據庫設計方法。2.3.2概念結構設計概念結構設計通常有以下四種方法：自頂向下自底向上逐步擴張混合策略其中，最常用的策略是自底向上方法，即自頂向下地進行需求分析，然后再自底向上地設計概念模型。2.3.2概念結構設計概念結構設計可分為以下兩個步驟:根據需求分析的結果，為每一個局部應用（或稱之為子系統）設計相應的局部概念模型（僅是局部用戶的數據視圖，有時又稱局部視圖），相應的E-R圖被稱為分E-R圖；將這些局部概念模型集成為一個全局概念模型（即總E-R圖，對系統中數據的整體結構進行描述），并對其進行驗證，以確保該全局概念模型的一致性，滿足需求分析階段確定的所有用戶需求，并最后征得用戶的認可。2.3.2概念結構設計

下面以學生信息管理系統為例具體說明概念結構設計的全過程。

為簡單起見，本系統僅考慮第1章所述的教務部門、學工部門和團學部門分別使用的學生選課信息管理、學生個人信息管理和學生社團信息管理3個子系統。2.3.2概念結構設計學生選課信息管理子系統主要用于教務部門對學生的選課及成績信息進行管理。首先，分析潛在的實體。其次，確定實體之間的聯系。2.3.2概念結構設計學生個人信息管理子系統主要用于學工部門對學生的個人信息及其獎懲情況進行管理。2.3.2概念結構設計學生社團信息管理子系統主要用于團學部門對學生參加社團的信息進行管理。2.3.2概念結構設計分E-R圖的集成合并。解決各分E-R圖之間的沖突，將各分E-R圖合并起來，生成初步E-R圖。修改和重構。消除不必要的冗余，生成總E-R圖。集成后的總E-R圖（這里省略了各個實體的屬性）2.3.2概念結構設計將局部概念模型集成為一個全局概念模型后，還需要對這個全局概念模型作進一步的驗證，以確保它能滿足以下三個條件：全局概念模型內部具有一致性，不存在相互矛盾的表達。全局概念模型應能準確反映原來的每一個局部概念模型。全局概念模型應能滿足需求分析階段確定的所有用戶需求。2.3.3邏輯結構設計概念模型是獨立于任何一種數據庫管理系統的、更加抽象的模型，若要在計算機上實現數據庫，還需選擇一種具體的數據庫管理系統，將概念模型（即概念結構設計階段得到的總E-R圖）轉換為數據庫賴以計算機實現的、由該數據庫管理系統支持的邏輯模型（如關系模型）。由于目前設計的數據庫應用系統大都采用關系數據庫管理系統，因此，這里只討論E-R圖向關系模型的轉換。2.3.3邏輯結構設計E-R圖向關系模型的轉換需要遵循以下原則：實體的轉換一個實體型轉換為一個關系模式，關系模式的屬性就是該實體的屬性，關系模式的碼就是該實體的碼。二元聯系的轉換——一對一聯系轉換為一個獨立的關系模式，關系模式的屬性包括與該聯系相連的兩端實體的碼以及聯系本身的屬性，關系模式的碼可以是任何一端實體的碼。可以和任何一端實體轉換得到的關系模式合并，即在被合并的關系模式中增加與該聯系相連的另一端實體的碼（將作為外碼存在于被合并的關系模式中）以及聯系本身的屬性，合并后的關系模式的碼保持不變。和哪一端的關系模式合并會更好一些呢？2.3.3邏輯結構設計E-R圖向關系模型的轉換需要遵循以下原則：二元聯系的轉換——一對多聯系轉換為一個獨立的關系模式，關系模式的屬性包括與該聯系相連的兩端實體的碼以及聯系本身的屬性，關系模式的碼只能是n端實體的碼。可以和n端實體轉換得到的關系模式合并，即在n端實體轉換得到的關系模式中增加與該聯系相連的另一端實體（即1端實體）的碼（將作為外碼存在于被合并的關系模式中）以及聯系本身的屬性，合并后的關系模式的碼保持不變。2.3.3邏輯結構設計E-R圖向關系模型的轉換需要遵循以下原則：二元聯系的轉換——多對多聯系轉換為一個獨立的關系模式，關系模式的屬性包括與該聯系相連的兩端實體的碼以及聯系本身的屬性，關系模式的碼由這兩個實體的碼共同組成，在這個獨立的關系模式中，它們也都是外碼。2.3.3邏輯結構設計E-R圖向關系模型的轉換需要遵循以下原則：多元聯系的轉換轉換為一個獨立的關系模式，關系模式的屬性包括與該聯系相連的各端實體的碼以及聯系本身的屬性，關系模式的碼由這些實體的碼共同組成，在這個獨立的關系模式中，它們也都是外碼。一元聯系的轉換同一個實體型內部各實體之間聯系（一對一、一對多、多對多）的轉換規則和二元聯系（一對一、一對多、多對多）的轉換規則相同。具有相同碼的關系模式可以合并具有相同碼的關系模式是否合并，主要看能否提升重要操作或數據庫總體（或期望）的執行效率。2.3.3邏輯結構設計根據以上轉換原則，學生信息管理系統的關系模型由以下7個關系模式組成：學生（學號，姓名，性別，出生日期，民族，政治面貌，聯系電話，班級，專業，年級，家庭住址，家長姓名，家長聯系電話）課程（課程號，課程名，學分）獎勵（獎勵編號，時間，級別，內容，等級，授予單位，學號）懲罰（懲罰編號，時間，原因，等級，撤銷時間，學號）社團（社團名稱，社團宗旨，成立時間）選修（學號，課程號，成績）參加（學號，社團名稱，參加時間，身份）2.3.3邏輯結構設計除了設計全局邏輯模型外，邏輯結構設計階段還要為具有不同數據需求的用戶設計相應的外模式。目前的關系數據庫管理系統都提供了視圖的概念，用視圖來設計外模式。和模式不同，在設計外模式時，主要考慮數據的安全性和用戶的使用習慣。為了進一步提高數據庫應用系統的性能，還應根據具體的應用需求對設計出來的數據模型進行適當的調整，這就是數據模型的優化。關系模型的優化通常以規范化理論作為指導。對某些關系模式進行合并或分解，在操作效率和潛在問題之間進行權衡。2.3.4規范化理論規范化理論不但可以用來指導關系模型的優化，而且還可以直接用來設計關系模式，這就是基于3NF的數據庫設計方法。針對一個具體應用，在設計數據庫的邏輯結構時，首先要考慮的基本問題就是：應該設計幾個關系模式，每個關系模式應該由哪些屬性組成，設計好的關系模式是不是一個“好”的關系模式等。針對這些問題，人們提出了關系數據庫的規范化理論。該理論可以用來判斷一個關系模式設計是否合理（規范），以及如何提高其規范程度進而降低潛在的異常問題等，從而成為指導數據庫邏輯結構設計的一個有力工具。2.3.4規范化理論關系模型要求關系必須是規范的，即要求關系必須滿足一定的規范性條件。滿足一定規范性條件的關系模式的集合稱為范式（NormalForm，NF）。前面提到的每一個分量都必須取不可再分的原子值只是其中最基本的規范性條件，滿足這一規范性條件的關系屬于第1范式（1NF），是規范程度最低的關系。這樣的關系會存在一些潛在的異常問題，因此還不能稱其為一個“好”的關系。2.3.4規范化理論現實世界的已知事實限定了關系模式必須滿足一定的完整性約束，這些約束或者通過對屬性取值范圍的限定，或者通過屬性間取值的相互依賴關系反映出來，后者稱為數據依賴，是判定關系模式是否規范的關鍵。數據依賴是通過一個關系中各屬性間取值的相等與否體現出來的數據間的相互依賴關系，是對現實世界中普遍存在的客觀聯系的抽象，是語義的體現。函數依賴（FunctionalDependency，簡稱FD）多值依賴（MultivaluedDependency，簡稱MVD）連接依賴（JoinDependency，簡稱JD）在關系模式的5元組R(U,D,dom,F)中，F就是屬性間的數據依賴集合，這里把關系模式簡記為R(U,F)。2.3.4規范化理論假設要建立一個描述學生基本情況的數據庫，涉及的數據包括：學生的學號sno、姓名sname、所屬的專業號mno、專業名mname、專業負責人mman、選修的課程號cno、課程名cname及其成績grade。如果采用單一的關系模式student(U,F)，則有：U={sno,sname,mno,mname,mman,cno,cname,grade}2.3.4規范化理論現實世界存在以下語義：每名學生都只有唯一的一個學號。每個專業都只有唯一的一個專業號。每門課程都只有唯一的一個課程號。一個專業只有一名專業負責人，一名專業負責人只管理一個專業。一個專業有若干名學生，但一名學生只屬于一個專業。一名學生可以選修多門課程，一門課程可由多名學生選修。每名學生選修每門課程只會有一個成績。據此可以得到U上的一組數據依賴，具體地說是函數依賴：F={sno→sname,sno→mno,mno→mname,mno→mman,

mnan→mno,cno→cname,

(sno,cno)→grade}該關系模式只有(sno,cno)這么一個候選碼。2.3.4規范化理論單一的關系模式student(U,F)會存在以下問題：插入異常刪除異常數據冗余度大和更新異常由于存在以上3個問題，該關系模式是一個“不好”的關系模式。如果按“一事一地”原則將其分解為以下4個關系模式：student(sno,sname,mno,sno→sname,sno→mno)major(mno,mname,mman,mno→mname,mno→mman,

mman→mno)course(cno,cname,cno→cname)score(sno,cno,grade,(sno,cno)→grade)就可以解決以上3個問題了。2.3.4規范化理論通過對關系模式的分解，使一個關系只描述一個實體型或實體間的一種聯系（和前面介紹的基于E-R圖的數據庫設計方法殊途同歸），可以提高其規范程度，達到消除異常的目的，這一過程就是規范化，從理論上講，就是用一組等價（不破壞原有數據）的規范程度更高的關系模式代替原來的規范程度較低的關系模式。關系模式規范程度的判定取決于其中存在什么樣的數據依賴，是否存在不合適的數據依賴，如果存在，是哪些不合適的數據依賴。2.3.4規范化理論函數依賴假設存在一個關系模式R(U)，X和Y是U的子集，若對于任一元組在X上的每一個值，都有Y上的唯一值與之對應，或者說，不存在兩個元組在X上的值相等但在Y上的值不等，則稱X函數決定Y，或稱Y函數依賴于X，記作：X→Y。X稱為決定屬性集或決定因子（Determinant）。若X→Y，且Y→X，則X與Y等價，記作：X←→Y。若X不函數決定Y，或Y不函數依賴于X，記作：X→Y。函數依賴是語義范疇的概念，需要根據具體語義來確定函數依賴。確定函數依賴可以從分析屬性間的聯系類型入手。2.3.4規范化理論由函數依賴的定義可知，函數依賴具有以下性質：若X→Y，X→Z，則X→Y∪Z（合并性）若X→Y∪Z，則X→Y，X→Z（分解性）若X→Y，Y→Z，則X→Z（傳遞性）若X→Y，則X∪Z→Y∪Z（增廣性）2.3.4規范化理論若X→Y，且

，則稱X→Y是非平凡的函數依賴；而若X→Y，且，則稱X→Y是平凡的函數依賴。在關系score(sno,cno,grade)中存在函數依賴：(sno,cno)→sno(sno,cno)→cno(sno,cno)→(sno,cno)(sno,cno)→grade除了最后一個函數依賴是非平凡函數依賴外，前3個函數依賴都是平凡函數依賴，在任何一個關系中都必然成立，不反映任何新的語義。若不作特殊說明，我們將只討論非平凡函數依賴。2.3.4規范化理論在關系模式R(U)中，若X→Y，并且對于X的任何一個真子集X’，都有X’→Y，則稱Y對X完全函數依賴，記作：X→Y

；而若X→Y，但Y不完全函數依賴于X，即存在X的一個真子集X’，有X’→Y，則稱Y對X部分函數依賴，記作：X→Y

。在student(sno,sname,mno,mname,mman,cno,cname,grade)中存在完全函數依賴：sno→sname，sno→mno，mno→mname，mno→mman，mnan→mno，cno→cname，(sno,cno)→grade據此，我們還可以推導出以下部分函數依賴：(sno,cno)→sname，(sno,cno)→mno，(sno,cno)→mname，(sno,cno)→mman，(sno,cno)→cnameFP2.3.4規范化理論在關系模式R(U)中，若X→Y（），Y→X，Y→Z（），則稱Z對X傳遞函數依賴。加上條件Y→X，是因為如果Y→X，則有X←→Y，那么Z對X就是直接函數依賴，而非傳遞函數依賴。加上條件和，說明Y對X和Z對Y都是非平凡的函數依賴。在關系student(sno,sname,mno,mname,mman,cno,cname,grade)中有sno→mno和mno→mman，根據函數依賴的傳遞性有sno→mman，因為mno→sno，所以mman對sno是傳遞函數依賴。2.3.4規范化理論在關系模式R(U,F)中，若存在屬性（或屬性組）K，使K→U成立，則稱K是R的候選碼。包含在任一候選碼中的屬性稱為主屬性。不包含在任何候選碼中的屬性稱為非主屬性或非碼屬性。F2.3.4規范化理論范式

范式級別較低的關系模式可以通過分解轉換為等價的具有較高范式級別的若干個關系模式，從而達到消除上述異常問題的目的，這一過程就稱為規范化。2.3.4規范化理論2NF若R∈1NF，且每一個非主屬性都完全函數依賴于候選碼，則R∈2NF。也就是說，2NF不允許非主屬性對候選碼部分函數依賴。在關系score(sno,cno,grade)中，候選碼只有一個，即(sno,cno)。因此，只有grade是非主屬性，因為(sno,cno)→grade，所以score∈2NF。在關系stud