在上學的時候，資料庫之中就講過資料庫正規化，現在突然想複習下，就上網查了下發現還是自己親自理一遍比較清晰
關聯式資料庫中的關係必須滿足一定的要求，即滿足不同的正規化。
目前關聯式資料庫有六種正規化：第一正規化（1nf）、第二正規化（2nf）、第三正規化（3nf）、第四正規化（4nf）、第五正規化（5nf）和第六正規化（6nf）。滿足最低要求的正規化是第一正規化（1nf）。在第一正規化的基礎上進一步滿足更多要求的稱為第二正規化（2nf），其餘正規化以次類推。一般說來，資料庫只需滿足第三正規化（3nf）就行了。
好傢伙，竟然一共有6種正規化- -汗，以前只知道第一第二第三正規化，好吧，貌似一二三也足夠解決問題了，那也就從一二三開始吧：
所謂第一正規化（1nf）是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性，就可能需要定義乙個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關係。在第一正規化（1nf）中表的每一行只包含乙個例項的資訊。簡而言之，第一正規化就是無重複的列。
說明：在任何乙個關聯式資料庫中，第一正規化（1nf）是對關係模式的基本要求，不滿足第一正規化（1nf）的資料庫就不是關聯式資料庫。
從上面這句話可以看出只要是能存進關係型資料庫的關係都算是滿足第一正規化，比方說有個字段是位址，網上很多人說這就不滿足資料庫第一正規化，我覺得這是曲解了第一正規化的原意，那究竟是什麼樣的情況下會違反這神奇的第一正規化呢？
idname
address
jim上海市虹口區xx號
hanson
北京市朝陽區xx號
能把以上的表存入關係型資料庫中嗎？顯然不行，所以第一正規化是防範以上情況的
完全依賴於主鍵 [消除非主屬性對主碼的部分函式依賴]
第二正規化（2nf）是在第一正規化（1nf）的基礎上建立起來的，即滿足第二正規化（2nf）必須先滿足第一正規化（1nf）。
第二正規化（2nf）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成乙個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上乙個列，以儲存各個例項的唯一標識。簡而言之，第二正規化就是屬性完全依賴於主鍵。
從上面可以看出來如果你的表如果只有乙個主鍵的話，那就一定滿足第二正規化，因為不存在部分函式依賴的限制
假設有如下的實體表：
此中departmentdescription欄位只是依賴與departmentname欄位，跟employeeid欄位沒啥關係，所以違反了第二正規化，那麼怎麼改呢？
不依賴於其它非主屬性[消除傳遞依賴]
滿足第三正規化（3nf）必須先滿足第二正規化（2nf）。第三正規化（3nf）要求乙個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。簡而言之，第三正規化就是屬性不依賴於其它非主屬性。
在上面的employee表中還有jobdescription依賴於job欄位，所以不滿足第三正規化，應作如下改變：
好了 資料庫三大正規化大功告成。至於剩下的第四第五第六那都是浮雲……
說一下，正規化的好處還是減少資料冗餘，並使結構更加清晰，以至於後期維護起來很容易，這我感覺是最重要的，因為如果你的資料庫設計得很爛的話，一些輕微的改動都沒法完成或付出很大的代價，那是很不值得的
至於到底要採用哪種正規化，我覺得還是得看業務需求，如果比較嚴謹的系統，對資料要求比較高，那麼相應的提高正規化的等級，但是如果是一些小系統，其實第二正規化就可以了，沒必要非要追求高正規化，因為企業還是得考慮成本等等因素，特別是如上面例子中僅僅是有
乙個字段傳遞依賴，在不重要的情況下完全可以忽略。
資料庫 資料庫正規化
關聯式資料庫的設計規範。不同的規範要求被稱為不同的正規化，越高的正規化資料庫冗餘越小。減少資料庫中資料冗餘的過程 1 第一正規化 1nf 在關係模式r中，當且僅當所有屬性只包含原子值，即每個分量都是不可再分的資料項，則稱r滿足1nf。例如表所示的教師職稱情況關係就不滿足1nf。原因在於，該關係模式中...
資料庫正規化 三正規化
所謂第一正規化 1nf 是指在關係模型中，對域新增的乙個規範要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子資料項，而不能是集合，陣列，記錄等非原子資料項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一正規化 1nf 表中的每個域值只能是實體的乙個屬性或乙個屬性的...
資料庫正規化
注 表在定義中被稱為關係,記作r 欄位在定義中被稱作屬性 模式 資料庫中有三種模式,外模式,內模式,模式 粗體是關鍵字的意思 斜體為外來鍵 以前寫下來的，但是用了多年的帳號已經忘了，唯有把文章轉到這裡來了 真暈哦 http blog.csdn.net fantasylu archive 2004 0...