數據庫設計範式的理解

前言
爲何要寫這篇文章呢，從去年年末開始，就和不少作技術的朋友交流過，從數據庫設計到數據庫架構各個方面的內容。有一些朋友執着於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的使用者以極大的誤導，從而忽視了是否新 特性是業務所真正須要的。

數據庫設計不是一種編程語言這麼簡單，與面向對象、面向過程無關。數據庫設計表明的是一種與應用開發語言徹底不一樣的思想。如今絕大多數的程序，不管任何人採用什麼方式進行程序開發，其最終仍是會迴歸到對數據庫的操做上（固然若是你的程序只是個教學演示則不在此範圍內）。

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

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

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

PS：這篇文章寫的很雜亂，尤爲是後面兩端，見諒！