前言
為什麼要寫這篇文章呢，從去年年底開始，就和很多做技術的朋友交流過，從資料庫設計到資料庫架構各個方面的內容。有一些朋友執著於orm，執著於所謂的資料庫設計，卻忘記了一切技術是要為業務服務這個基石。當然這文章裡也有一些自己的理解，想向大家表達。
正規化是什麼
正規化是符合某一種級別的關係模式的集合。關聯式資料庫中的關係必須滿足一定的要求，即滿足不同的正規化。目前關聯式資料庫有六種正規化：第一正規化（1nf）、第二正規化（2nf）、第三正規化（3nf）、第四正規化（4nf）、第五正規化（5nf）和第六正規化（6nf）。滿足最低要求的正規化是第一正規化（1nf）。在第一正規化的基礎上進一步滿足更多要求的稱為第二正規化（2nf），其餘正規化以次類推。一般說來，資料庫只需滿足第三正規化（3nf）就行了。
目前有跡可尋的共有8種正規化，依次是：1nf，2nf，3nf，bcnf，4nf，5nf，dknf，6nf。
正規化的原理
所謂第一正規化（1nf）是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性，就可能需要定義乙個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關係。在第一正規化（1nf）中表的每一行只包含乙個例項的資訊。簡而言之，第一正規化就是無重複的列。
說明：在任何乙個關聯式資料庫中，第一正規化（1nf）是對關係模式的基本要求，不滿足第一正規化（1nf）的資料庫就不是關聯式資料庫。
第二正規化（2nf）是在第一正規化（1nf）的基礎上建立起來的，即滿足第二正規化（2nf）必須先滿足第一正規化（1nf）。第二正規化（2nf）要求資料庫表中的每個例項或行必須可以被惟一地區分。為實現區分通常需要為表加上乙個列，以儲存各個例項的惟一標識。
例如員工資訊表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二正規化（2nf）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成乙個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上乙個列，以儲存各個例項的惟一標識。簡而言之，第二正規化就是屬性完全依賴於主鍵。
滿足第三正規化（3nf）必須先滿足第二正規化（2nf）。簡而言之，第三正規化（3nf）要求乙個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。例如，存在乙個部門資訊表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等資訊。
那麼在的員工資訊表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的資訊再加入員工資訊表中。如果不存在部門資訊表，則根據第三正規化（3nf）也應該構建它，否則就會有大量的資料冗餘。簡而言之，第三正規化就是屬性不依賴於其它非主屬性。
正規化的說明
通俗的理解是字段還可以再分嗎？如過不能，則是符合1nf的設計。
簡單的解釋，比如你和乙個女生約會建立一張表，不用每條約會記錄都記錄她的身高、體重，將身高體重單獨的存在一張表中供查詢即可。
我對正規化的理解
乙個嚴格恪守資料庫設計正規化來進行資料庫設計的人，必定是個傻球；
乙個沒有研究過資料庫設計正規化就進行資料庫設計的人，必定也是個傻球；
在現代資料庫設計中，尤其是web 2.0的系統中的資料庫設計，我可以斷言，大多數都是違反2nf、3nf的，少數設計甚至是違反1nf的。資料庫設計正規化只是對資料庫慣用設計的一些說明，並不能定性為標準。
而從資料庫的發展來看，以mysql舉例，隨著mysql實現越來越多的功能，它的宣傳材料上會越來越多的出現以前被mysql所摒棄的複雜設計理念，並且宣稱這是mysql所獨創或一貫倡導的。這是乙個資料庫系統發展所必然經歷的過程。而這卻會給mysql的使用者以極大的誤導，從而忽視了是否新特性是業務所真正需要的。
資料庫設計不是一種程式語言這麼簡單，與物件導向、面向過程無關。資料庫設計代表的是一種與應用開發語言完全不同的思想。現在絕大多數的程式，無論任何人採用什麼方式進行程式開發，其最終還是會回歸到對資料庫的操作上（當然如果你的程式只是個教學演示則不在此範圍內）。
資料庫發展
從下面的列表可以看出當前sns的**對於高併發、高效能的資料庫解決方案有多麼渴求，facebook貢獻了cassandra、linkedin貢獻了voldemort、mixi.jp貢獻了tokyo cabinet和tokoy tyrant、green.jp貢獻了flare、甚至包括google的bigtable。
總結
寫到這裡，我發現單單是這些新的資料庫解決方案就有太多可寫的內容，而這些已經超過了本文所要說明的主要內容，而現在所寫的內容就全當是個引子吧，我寫的很意猶未盡。後面會就反正規化設計例項，記憶體快取方案、nosql資料庫等逐漸展開。
其實以上只能作為參考，實際設計時不會完全按照正規化。
應該的原則：
資料庫查詢越少越好，
sql語句越簡單越好。
資料庫設計正規化
目前關聯式資料庫有六種正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 第四正規化 4nf 第五正規化 5nf 和第六正規化 6nf 滿足最低要求的正規化是第一正規化 1nf 在第一正規化的基礎上進一步滿足更多要求的稱為第二正規化 2nf 其餘正規化以次類推。一般說來，資料庫只需滿...
資料庫正規化設計
在軟體開發過程中，資料庫的設計是非常重要的。可以說，良好的資料庫設計，是對使用者需求的理解的精準定位。它不僅能夠使得軟體開發起來非常便捷，而且還能夠使軟體系統高效執行，同時，為日後的維護或者更換資料庫提供便利。在最近開發系統的過程中，感覺收穫最大的也是關於資料庫的操作。最初開發機房收費系統的時候，由...
資料庫設計 正規化
本文介紹常用的第一正規化 第二正規化 第三正規化以及bc正規化。在理解正規化前需要先了解一些基本概念。基本概念 碼 乙個屬性或者屬性組，使得整個關係中除過此屬性或者屬性組之外的其餘屬性都完全函式依賴於它，那它就是碼。在乙個關係中可以同時存在多個碼。主碼 從候選碼中挑選的其中乙個稱為主碼。主鍵 從候選...