構造數據庫必須遵循一定的規則。在關系數據庫中，這種規則就是范式。范式是符合某一種級別的關系模式的集合。關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多要求的稱為第二范式（2NF），其余范式以次類推。一般說來，數據庫只需滿足第三范式（3NF）就行了。下面我們舉例介紹第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

3.4.1 第一范式（1NF）
    在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。
     所謂第一范式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一范式（1NF）中表的每一行只包含一個實例的信息。例如，對于圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一范式就是無重復的列。

3.4.2 第二范式（2NF）
    第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如
圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
     第二范式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二范式就是非主屬性非部分依賴于主關鍵字。

3.4.3 第三范式（3NF）
    滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在圖3-2
的員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。簡而言之，第三范式就是屬性不依賴于其它非主屬性。


所謂范式就是符合某一種級別的關系模式的集合。通過分解把屬于低級范式的關系模式轉換為幾個屬于高級范式的關系模式的集合。這一過程稱為規范化。   
    
  1、   第一范式（1NF）：一個關系模式R的所有屬性都是不可分的基本數據項。   
  2、   第二范式（2NF）：關系模式R屬于第一范式，且每個非主屬性都完全函數依賴于鍵碼。   
  3、   第三范式（3NF）：關系模式R屬于第一范式，且每個非主屬性都不偉遞領帶于鍵碼。   
  4、   BC范式（BCNF）：關系模式R屬于第一范式，且每個屬性都不傳遞依賴于鍵碼。

一、范式例子   
    
  定義：   
  =====   
  第一范式：（1NF）   
  如果關系模式，它的每一分量是不可分的數據項，則此關系模式為第一范式   
  第二范式：（2NF）   
  若關系模式R屬于1NF，且每個非主屬性完全依賴于碼，則R為2NF   
  第三范式：（3NF）   
  若關系模式R屬于2NF，不存在非主屬性對碼的傳遞依賴，則稱R為3NF   
  傳遞依賴：當屬性間存在X->Y,Y-\->X,Y->Z,稱z傳遞依賴與X   
    
  舉例：   
  =====   
  將有關學生簡歷、選課等數據設計成一關系模式student   
  表示為：   
  student(sno,sname,age,sex,class,department,cno,cname,score,grade)   
  -----------------------------------------------------------------   
  該關系模式的每一屬性對應的域為簡單域，符合第一范式   
  該關系模式滿足函數依賴集   
  F={sno->sname,sno->age,sno->sex,sno->class,sno->department   
        class->departmet     (班級決定系)   
        cno->cname,cno->score(課程號決定課程名、學分)   
        sno,cno->grade(學號和課程號決定成績）   
      }   
  下面將低級范式的關系模式轉換成若干個高一級范式的關系模式集合   
  student1(sno,sname,age,sex,class,department)   
  --------------------------------------------   
  course(cno,cname,score)   
  -------------------------   
  sc(sno,cno,grade)   
  -----------------   
  非主屬性對碼完全依賴，均為2NF   
    
  分析模式student1,存在sno->class   ,class-\->sno,class->department   
  所以存在department(系)對sno(學號)傳遞依賴，所以關系模式student1不是第三范式   
  student1分解為:   
  student2(sno,sname,age,sex,class)   
  ---------------------------------   
  class(class,department)   
  -----------------------   
  所以關系模式student   可分解成   4個3NF的關系模式student2   ,class   ,course,sc   

其實范式是關系型數據的基本知識.   
  1Nf--第1范式就是沒有表中有表,即二維表就可以了   
  2Nf--第2范式就是表中沒有重復列.   
  3Nf--第3范式就是沒有傳遞依賴,表中所有列都函數依賴于主關鍵字.(比如,表a(ID,sum1,Sid,a1),表b(Sid,a1)例子中ID為表a的關鍵字,Sid為表b的關鍵字.   
  我們說表a傳遞依賴于表b,應該規范為表a(ID,sum1,Sid),表b(Sid,a1)   
    
  一般要求關系表能夠滿足第3范式就可以了.   


3NF的規則是：在滿足第2NF的規則的基礎上，非主鍵字段必須直接依賴于主鍵。   
    
  而BCNF的規則是：非主鍵字段必須依賴于整個主鍵字！   
    
  也就是說，要想達到BCNF的標準，還要在3NF的基礎上基礎拆分表。

鮑依斯-科得范式（BCNF）：在第三范式的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合BCNF   。   
  　　假設倉庫管理關系表為StorehouseManage(倉庫ID,   存儲物品ID,   管理員ID,   數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個數據庫表中存在如下決定關系：　　(倉庫ID,   存儲物品ID)   →(管理員ID,   數量)       　(管理員ID,   存儲物品ID)   →   (倉庫ID,   數量)   
  　所以，(倉庫ID,   存儲物品ID)和(管理員ID,   存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三范式的。但是，由于存在如下決定關系：　　(倉庫ID)   →   (管理員ID)               (管理員ID)   →   (倉庫ID)


數據庫的設計范式是數據庫設計所需要滿足的規范，滿足這些規范的數據庫是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給數據庫的編程人員制造麻煩，而且面目可憎，可能存儲了大量不需要的冗余信息。

　　設計范式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照范式來設計數據庫。

　　實質上，設計范式用很形象、很簡潔的話語就能說清楚，道明白。本文將對范式進行通俗地說明，并以筆者曾經設計的一個簡單論壇的數據庫為例來講解怎樣將這些范式應用于實際工程。

　　范式說明

　　第一范式（1NF）：數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。

　　例如，如下的數據庫表是符合第一范式的：

字段1  字段2  字段3  字段4 
        

　　而這樣的數據庫表是不符合第一范式的：

字段1  字段2  字段3  字段4 
    字段3.1 字段3.2    



　　很顯然，在當前的任何關系數據庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一范式的數據庫，因為這些DBMS不允許你把數據庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一范式的數據庫都是不可能的。

　　第二范式（2NF）：數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字。   
  


　　假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：

　　(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

　　這個數據庫表不滿足第二范式，因為存在如下決定關系：

　　(課程名稱) → (學分)

　　(學號) → (姓名, 年齡)

　　即存在組合關鍵字中的字段決定非關鍵字的情況。

　　由于不符合2NF，這個選課關系表會存在如下問題：

　　(1) 數據冗余：

　　同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。

　　(2) 更新異常：

　　若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。

　　(3) 插入異常：

　　假設要開設一門新的課程，暫時還沒有人選修。這樣，由于還沒有"學號"關鍵字，課程名稱和學分也無法記錄入數據庫。

　　(4) 刪除異常：

　　假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。 

　　把選課關系表SelectCourse改為如下三個表：