註： 本文不對三範式的概念進行介紹，只舉例說明本人對三範式的理解！歡迎斧正！ 第一範式：1NF 1、確保創建表時的每一列屬性的原子性，即每一列屬性都是不可再分的屬性值。 （1）例如： （1）解釋： user_address 屬性不符合屬性的原子性，該屬性可以進一步進行拆分成，省、市、縣、詳細地址等信 ...
註： 本文不對三範式的概念進行介紹，只舉例說明本人對三範式的理解！歡迎斧正！
第一範式：1NF
1、確保創建表時的每一列屬性的原子性，即每一列屬性都是不可再分的屬性值。
（1）例如：
（1）解釋：
user_address 屬性不符合屬性的原子性，該屬性可以進一步進行拆分成，省、市、縣、詳細地址等信息！
（2）例如：
（2）解釋：
將原user_address屬性拆分成省份、地市信息（int類型數據字典值），根據具體需求可以將詳細地址進一步進行拆分，定位到城區，縣市，甚至是小區名稱，建築物名稱等！
所以所謂屬性的原子性也要結合具體需求實現相應粒度的原子性！例如：要對用戶的省市信息進行分組表1顯然不滿足需求、要對區縣信息進行分組表2仍不滿足需求，應進一步將user_address進行原子性拆分。
2、同一個數據表中不得存在類型相似的屬性
（1）例如：
（1）解釋：
user_provence_2 等屬性與user_provence等屬性重覆，當前表既無法滿足用戶有多個收貨地址的情況，當只存在一個收貨地址的情況下，又會造成欄位冗餘！
創建收貨地址表，解決屬性相似問題，及多個收貨地址的情況！
第二範式：2NF
1、一張表在滿足1NF的前提下，表中其他非主屬性又統一直接依賴表中唯一主屬性（primary key）則滿足2NF！
2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性，更通俗說有主鍵ID。
（1）例如：
（1）解釋：
在用戶表中存在非主屬性[order_info]不與該表主屬性[user_id]直接關聯（order_info與order_id直接關聯），即當前表不滿足2NF。
應將訂單表與用戶表分離，訂單表通過關聯用戶表user_id實現主從模式[1用戶—n訂單] 綁定。保證了一個表只保存一類業務實體。
第三範式：3NF
1、數據表中不存在屬性的依賴傳遞
（1）示例：
（1）解釋：3NF是對欄位冗餘性的約束，即任何欄位不能由其他欄位派生出來，它要求欄位沒有冗餘。
乍一看，code能決定其他非主屬性，符合2NF。但是在同系的學生中，系相關信息被保存n份。
(1)造成了數據冗餘，同系學生的系相關信息相同。
(2)修改系相關信息，則需要修改所有學生的系信息。
解決辦法：分表操作！
解決表中的依賴傳遞現象，code—>d_code ，d_code 能決定d_name/d_address ，則code影響d_name/d_address是通過code—>d_code 進行的依賴傳遞實現的。
基於三範式的資料庫設計屬於學院派的數據表設計風格，並不是所以的表設計都要滿足三範式！在真正的生產環境下，主要依據業務需求結合數據規模等各種因素的綜合影響下對錶結構進行設計！切不可拘泥於範式的約束！
