范式：英文名稱是 Normal Form，它是英國人 E.F.Codd（關系數(shù)據(jù)庫的老祖宗）在上個世紀70年代提出關系數(shù)據(jù)庫模型后總結出來的索绪，范式是關系數(shù)據(jù)庫理論的基礎湖员，也是我們在設計數(shù)據(jù)庫結構過程中所要遵循的規(guī)則和指導方法。目前有跡可尋的共有8種范式瑞驱，依次是：1NF娘摔，2NF，3NF唤反，BCNF晰筛，4NF，5NF拴袭，DKNF，6NF曙博。通常所用到的只是前三個范式拥刻，即：第一范式（1NF），第二范式（2NF）父泳，第三范式（3NF）般哼。
設計關系數(shù)據(jù)庫時吴汪，遵從不同的規(guī)范要求，設計出合理的關系型數(shù)據(jù)庫蒸眠，這些不同的規(guī)范要求被稱為不同的范式漾橙，各種范式呈遞次規(guī)范，越高的范式數(shù)據(jù)庫冗余越小楞卡。
目前關系數(shù)據(jù)庫有六種范式：第一范式（1NF）霜运、第二范式（2NF）、第三范式（3NF）蒋腮、巴斯-科德范式（BCNF）淘捡、第四范式(4NF）和第五范式（5NF，又稱完美范式）池摧。滿足最低要求的范式是第一范式（1NF）焦除。在第一范式的基礎上進一步滿足更多規(guī)范要求的稱為第二范式（2NF），其余范式以次類推作彤。一般說來膘魄，數(shù)據(jù)庫只需滿足第三范式(3NF）就行了。
下面就簡單介紹下這三個范式竭讳。
第一范式（1NF）
強調(diào)的是列的原子性创葡，即列不能夠再分成其他幾列。
考慮這樣一個表：【聯(lián)系人】（姓名代咸，性別蹈丸，電話）
如果在實際場景中，一個聯(lián)系人有家庭電話和公司電話呐芥，那么這種表結構設計就沒有達到 1NF逻杖。要符合 1NF 我們只需把列（電話）拆分，即：【聯(lián)系人】（姓名思瘟，性別荸百，家庭電話，公司電話）滨攻。1NF 很好辨別够话，但是 2NF 和 3NF 就容易搞混淆。
說明：在任何一個關系數(shù)據(jù)庫中光绕，第一范式（1NF）是對關系模式的設計基本要求女嘲，一般設計中都必須滿足第一范式（1NF）。不過有些關系模型中突破了1NF的限制诞帐，這種稱為非1NF的關系模型欣尼。換句話說，是否必須滿足1NF的最低要求停蕉，主要依賴于所使用的關系模型愕鼓。
第二范式（2NF）
首先是 1NF钙态，另外包含兩部分內(nèi)容，一是表必須有一個主鍵菇晃；二是沒有包含在主鍵中的列必須完全依賴于主鍵册倒，而不能只依賴于主鍵的一部分。
考慮一個訂單明細表：【OrderDetail】（OrderID磺送，ProductID驻子，UnitPrice，Discount册着，Quantity拴孤，ProductName）。
因為我們知道在一個訂單中可以訂購多種產(chǎn)品甲捏，所以單單一個 OrderID 是不足以成為主鍵的演熟，主鍵應該是（OrderID，ProductID）司顿。顯而易見 Discount（折扣）芒粹，Quantity（數(shù)量）完全依賴（取決）于主鍵（OderID，ProductID）大溜，而 UnitPrice化漆，ProductName 只依賴于 ProductID。所以 OrderDetail 表不符合 2NF钦奋。不符合 2NF 的設計容易產(chǎn)生冗余數(shù)據(jù)座云。
可以把【OrderDetail】表拆分為【OrderDetail】（OrderID，ProductID付材，Discount朦拖，Quantity）和【Product】（ProductID，UnitPrice厌衔，ProductName）來消除原訂單表中UnitPrice璧帝，ProductName多次重復的情況。
第二范式（2NF）要求實體的屬性完全依賴于主關鍵字富寿。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性睬隶，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體页徐，新實體與原實體之間是一對多的關系苏潜。為實現(xiàn)區(qū)分通常需要為表加上一個列，以存儲各個實例的唯一標識变勇。簡而言之窖贤，第二范式就是在第一范式的基礎上屬性完全依賴于主鍵。
第三范式（3NF）
在1NF基礎上，任何非主屬性不依賴于其它非主屬性[在2NF基礎上消除傳遞依賴]赃梧。
第三范式（3NF）是第二范式（2NF）的一個子集，即滿足第三范式（3NF）必須滿足第二范式（2NF）豌熄。
首先是 2NF授嘀，另外非主鍵列必須直接依賴于主鍵，不能存在傳遞依賴锣险。即不能存在：非主鍵列 A 依賴于非主鍵列 B蹄皱，非主鍵列 B 依賴于主鍵的情況。 考慮一個訂單表【Order】（OrderID芯肤，OrderDate巷折，CustomerID，CustomerName崖咨，CustomerAddr锻拘，CustomerCity）主鍵是（OrderID）。
其中 OrderDate击蹲，CustomerID署拟，CustomerName，CustomerAddr歌豺，CustomerCity 等非主鍵列都完全依賴于主鍵（OrderID）推穷，所以符合 2NF。不過問題是 CustomerName类咧，CustomerAddr馒铃，CustomerCity 直接依賴的是 CustomerID（非主鍵列），而不是直接依賴于主鍵痕惋，它是通過傳遞才依賴于主鍵区宇，所以不符合 3NF。
通過拆分【Order】為【Order】（OrderID血巍，OrderDate萧锉，CustomerID）和【Customer】（CustomerID，CustomerName述寡，CustomerAddr柿隙，CustomerCity）從而達到 3NF。
第二范式（2NF）和第三范式（3NF）的概念很容易混淆鲫凶，區(qū)分它們的關鍵點在于禀崖，2NF：非主鍵列是否完全依賴于主鍵，還是依賴于主鍵的一部分螟炫；3NF：非主鍵列是直接依賴于主鍵波附，還是直接依賴于非主鍵列。
BCNF(BC范式)
它構建在第三范式的基礎上，如果關系模型R是第一范式掸屡，且每個屬性都不傳遞依賴于R的候選鍵封寞，那么稱R為BCNF的模式。
假設倉庫管理關系表(倉庫號仅财，存儲物品號狈究，管理員號，數(shù)量)盏求，滿足一個管理員只在一個倉庫工作抖锥；一個倉庫可以存儲多種物品，則存在如下關系：
(倉庫號碎罚，存儲物品號)——>(管理員號磅废，數(shù)量)
(管理員號，存儲物品號)——>(倉庫號荆烈，數(shù)量)
所以拯勉，(倉庫號，存儲物品號)和(管理員號耙考，存儲物品號)都是倉庫管理關系表的候選碼谜喊，表中唯一非關鍵字段為數(shù)量，它是符合第三范式的倦始。但是斗遏，由于存在如下決定關系：
(倉庫號)——>(管理員號)
(管理員號)——>(倉庫號)
即存在關鍵字段決定關鍵字段的情況，因此其不符合BCNF鞋邑。把倉庫管理關系表分解為兩個關系表倉庫管理表(倉庫號诵次，管理員號)和倉庫表(倉庫號，存儲物品號枚碗，數(shù)量)逾一，這樣這個數(shù)據(jù)庫表是符合BCNF的肮雨，并消除了刪除異常遵堵、插入異常和更新異常。
4NF(第四范式)
設R是一個關系模型怨规，D是R上的多值依賴集合陌宿。如果D中存在凡多值依賴X->Y時，X必是R的超鍵波丰，那么稱R是第四范式的模式壳坪。
例如，職工表(職工編號掰烟，職工孩子姓名爽蝴，職工選修課程)沐批，在這個表中，同一個職工可能會有多個職工孩子姓名蝎亚，同樣九孩，同一個職工也可能會有多個職工選修課程，即這里存在著多值事實颖对，不符合第四范式捻撑。如果要符合第四范式，只需要將上表分為兩個表缤底，使它們只有一個多值事實，例如職工表一(職工編號番捂，職工孩子姓名)个唧，職工表二(職工編號，職工選修課程)设预，兩個表都只有一個多值事實徙歼，所以符合第四范式。
拓展：各范式的關系圖如下所示：
