實踐千萬條，基礎第一條——數據庫範式

　　在當前互聯網流行架構下，Redis、MongoDB等非關係型數據庫（NoSQL）正逐漸搶佔更多的視野，然而正如其釋義（Not Only SQL）所說，NoSQL在當前仍然只做爲傳統關係型數據庫的補充。當前的的大部分持久化場景下，關係型數據庫仍然佔據不可替代的地位。所以，可以設計出規範合理的關係數據表也是全部後端程序員的必修功課，然而「規範合理」是否又有一個量化的指標呢？一般領域下答案是沒有，但在關係數據庫下還真的有，這就是咱們常說的「數據庫範式」。

　　「來，你給翻譯翻譯，什麼叫範式？」

　　「不用翻譯，就是範式啊！」

　　「我讓你翻譯給我聽，什麼叫範式？」

　　「範式就是一種最佳實踐」

　　「翻譯翻譯，什麼叫**的範式？」

　　「範式就是一種前人通過無數次實踐與論證，得出的經驗總結！」

　　「我讓你翻譯翻譯，什麼**的叫**的範式？」

　　「你最好這麼幹，否則就是你錯了，得拉出去槍斃！」

　　「哦，原來這就是範式啊！」

　　提及數據庫範式，目前關係數據庫共有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式（4NF）和第五範式（5NF，又稱完美範式），咱們廣泛認爲達到第三範式就是較爲合理的設計方案了，本篇文章也主要針對前三個範式作一個通俗解釋。

 

　　標準的三大範式定義：

　　　　第一範式：當關系模式R的全部屬性都不能在分解爲更基本的數據單位時，稱R是知足第一範式的，簡記爲1NF。知足第一範式是關係模式規範化的最低要求，不然，將有不少基本操做在這樣的關係模式中實現不了。

　　　　第二範式：若是關係模式R知足第一範式，而且R的全部非主屬性都徹底依賴於R的每個候選關鍵屬性，稱R知足第二範式，簡記爲2NF。

　　　　第三範式：若是關係模式R知足第二範式，X是R的任意屬性集，若是X非傳遞依賴於R的任意一個候選關鍵字，稱R知足第三範式，簡記爲3NF。

 

　　什麼，定義太長了，還好下面有一個精簡的版本：

　　　　第一範式：表中不能有表，列中不能有列。

　　　　第二範式：知足第一範式的基礎上，消除非主屬性對主屬性的部分依賴。

　　　　第三範式：知足第二範式的基礎上，消除非主屬性對任一主屬性的傳遞依賴。

 

　　如下將嘗試對上面的釋義作一個通俗的解釋：

　　第一範式：表中不能有表，列中不能有列。這是對關係數據表的基本要求，同時相信也沒有人可以在物理上突破限制，真的在表裏建出另外一張子表。然而，邏輯上的「列中不能有列」卻經常被人忽略。例如，記錄用戶信息的用戶表中有一個字段realname，記錄用戶姓名，這在中國倒很常見，但如果放眼全球，不少國家以firstname，lastname來標記姓名，仍然堅持以一個字段來記錄姓名便會經常出現問題。所以，並非全部關係表都能輕鬆達到嚴格的第一範式哦！

　　第二範式：舉個反例，設計一張學分表，包含字段course_id(課程),stu_no(學號)，score(學分)，stu_name(姓名)。相信不少人看到這樣的表結構很快就能感覺到一股奇怪的力量，沒錯，就是stu_name亂入了，這張表的主屬性是course_id和stu_no，score徹底依賴於主屬性，而stu_name卻只依賴於stu_no不依賴於course_id，這即是部分依賴，所以，將stu_name移出表結構的過程就是消除非主屬性對於主屬性部分依賴的過程。

　　第三範式：仍然以例爲證，設計一張訂單表，order_id(訂單號)，total_fee(總價)，customer_id(顧客id)，customer_name(顧客姓名)。其中主屬性是order_id，其餘屬性所有依賴於order_id，所以能夠認爲當前表結構知足第二範式，然而，customer_id依賴於order_id，而customer_name又依賴於customer_id，這便致使了一條傳遞依賴，不知足第三範式，所以將customer_name移出表結構的過程就是消除非主屬性對主屬性的傳遞依賴的過程。

 

　　Tips：本質上，數據庫範式的演變過程就是去除冗餘數據的過程，在實踐中，瞭解三大範式對於數據庫的設計將會大有裨益，但切記不能鑽牛角尖，由於業務場景的複雜度不在數據庫範式討論的範圍以內，若是一味強求數據庫的設計規範，很容易增長數據庫的設計和程序編碼的複雜度，所以，適當合理的數據冗餘也是能夠接受的哦！遺憾的是，「適當合理的數據冗餘」並無量化的概念呢！