第一正規化(1NF)

資料表的每個欄位(屬性)必須是唯一的、不可分割的。

比如說：在一張學生資訊表裡不能有兩個名稱都是name的欄位。

比如說：在一張學生資訊表不能出現類似name_mobile這樣的欄位，很明顯name_mobile是可以分割成name和mobile兩個欄位的。

第二正規化(2NF)

資料表的每條記錄必須是唯一的(主鍵約束)，且非主屬性依賴於主屬性。

比如說：不能同時存在id ＝ 1的記錄（id為主鍵）。

比如說：在一張學生資訊表（id為主鍵），不應該出現course_name(課程名稱，依賴於course_id)這樣的欄位，因為，如果有一天，《心理健康教育》課程名要改成《心理健康教育雜談》，這就得需要改課程表，還得回來修改學生資訊表的課程名稱。

第三正規化(3NF)

資料表中不應該存在多餘的欄位，也就是說每個欄位都不能由其他欄位推理得到。

比如說：學生資訊表裡不能同時存在province_id(省份ID)、city_id(城市ID)這兩個欄位，因為province_id可以由city_id推理得到

欄位冗餘

資料表中存在多餘的欄位。 例如：訂單表：訂單資訊，商品id，商品名稱。這裡的商品名稱是冗餘的，在商品表中有這個欄位，根據商品id可以關聯到。 毫無疑問，欄位冗餘是違反第三正規化的。

1.考慮效能：以時間換空間 在資料庫的實踐過程中，我們可能遇到資料量非常大的資料表，這時候去做join查詢是非常損耗效能的，甚至導致資料庫連線超時、掛掉等問題。所以呢，有時候就需要資料庫多冗餘設計，對一些欄位做冗餘到關聯表中，以避免大表之間的join。

弊端：難以維護。更新表資料時需要同時更新多個表。 比如，order：orderid，userid，username；user：userid，username。當用戶更改username時，所有有username的表都需要update。

2.考慮業務：快照場景 交易場景大部分是資料快照。使用者下單時候的使用者名稱、地址、商品名稱、商品描述等，若採用關聯，商品在下單後發生了更新的話再去關聯查詢就會導致和使用者操作時的資料不一致，從而產生糾紛。 比如，order：orderid，goodsid；goods：goodsid，price。使用者今天下單，價格為100。過了幾天賣家漲價了，價格漲為200。使用者申請退款，系統給他退款200。這顯然不合理。所以這裡price需要冗餘，order：orderid，goodsid，price；goods：goodsid，price。 其實嚴格來講，這也可以說不是冗餘，因為兩個表中的price含義有所區別。order表中的price表示“下訂單時的商品價格”，goods表中的price表示“商品現在的價格”。