前言
為什么要寫這篇文章呢，從去年年底開始，就和很多做技術的朋友交流過，從數據庫設計到數據庫架構各個方面的內容。有一些朋友執著于ORM，執著于所謂的數據庫設計，卻忘記了一切技術是要為業務服務這個基石。當然這文章里也有一些自己的理解，想向大家表達。

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

范式的原理

• 第一范式（1NF）無重復的列

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

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

• 第二范式（2NF）屬性完全依賴于主鍵 [消除部分子函數依賴]

  第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。

  例如員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。

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

• 第三范式（3NF）屬性不依賴于其它非主屬性 [消除傳遞依賴]

  滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。

  那么在的員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。簡而言之，第三范式就是屬性不依賴于其它非主屬性。

范式的說明

• 第一范式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解；

  通俗的理解是字段還可以再分嗎？如過不能，則是符合1NF的設計。

• 第二范式：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性；

  簡單的解釋，比如你和一個女生約會建立一張表，不用每條約會記錄都記錄她的身高、體重，將身高體重單獨的存在一張表中供查詢即可。

• 第三范式：3NF是對字段冗余性的約束，即任何字段不能由其他字段派生出來，它要求字段沒有冗余。
  打個比方，比如評論表，如果你將用戶ID，用戶頭像都放在這留言表中，就是不合適的了。用戶頭像是依賴于用戶ID，而不依賴該評論。

我對范式的理解
一個嚴格恪守數據庫設計范式來進行數據庫設計的人，必定是個傻球；
一個沒有研究過數據庫設計范式就進行數據庫設計的人，必定也是個傻球；

在現代數據庫設計中，尤其是web 2.0的系統中的數據庫設計，我可以斷言，大多數都是違反2NF、3NF的，少數設計甚至是違反1NF的。數據庫設計范式只是對數據庫慣用設計的一些說明，并不能定性為標準。

而從數據庫的發展來看，以MySQL舉例，隨著MySQL實現越來越多的功能，它的宣傳材料上會越來越多的出現以前被MySQL所摒棄的復雜設計理念，并且宣稱這是MySQL所獨創或一貫倡導的。這是一個數據庫系統發展所必然經歷的過程。而這卻會給MySQL的使用者以極大的誤導，從而忽視了是否新特性是業務所真正需要的。

數據庫設計不是一種編程語言這么簡單，與面向對象、面向過程無關。數據庫設計代表的是一種與應用開發語言完全不同的思想?，F在絕大多數的程序，無論任何人采用什么方式進行程序開發，其最終還是會回歸到對數據庫的操作上（當然如果你的程序只是個教學演示則不在此范圍內）。

數據庫發展
各種緩存方案，說到底是以key為基礎的數據解決方案，而數據庫與應用層之間的中間件，為了實現邏輯的簡單和高性能，更多的也會是基于key的實現。比如我所使用過的騰訊的TTC。

從下面的列表可以看出當前SNS的網站對于高并發、高性能的數據庫解決方案有多么渴求，Facebook貢獻了Cassandra、Linkedin貢獻了Voldemort、mixi.jp貢獻了Tokyo Cabinet和Tokoy Tyrant、green.jp貢獻了Flare、甚至包括Google的BigTable。

總結
寫到這里，我發現單單是這些新的數據庫解決方案就有太多可寫的內容，而這些已經超過了本文所要說明的主要內容，而現在所寫的內容就全當是個引子吧，我寫的很意猶未盡。后面會就反范式設計實例，內存緩存方案、NoSQL數據庫等逐漸展開。

數據庫設計范式的理解