例如：字段「使用者身份標識」：usertype-userid。 這個字段「使用者身份表」可以再分為「使用者型別」和「使用者id標識」。
常規做法：只要給表乙個「id」字段，並設定自動增長，其實就是取消掉復合主鍵。通過另乙個單一欄位的主鍵來代替。一句話，沒有復合主鍵，就沒有部分依賴。
舉例：s1（sno，sname，dno，dname，location） 各屬性分別代表學號，
姓名，所在系，系名稱，系位址。
關鍵字sno決定各個屬性。由於是單個關鍵字，沒有部分依賴的問題，肯定是符合第二正規化的。但這關係肯定有大量的冗餘，有關學生所在的幾個屬性dno，dname，location將重複儲存，插入，刪除和修改時也將產生類似以上例的情況。
解決方法：分為兩個關係 s（sno，sname，dno），d（dno，dname，location）。
通過正規化理論所設計的資料庫schema 邏輯清晰，關係明確，擴充套件方便，就連儲存的資料量也做到了盡可能的少，尤其是當正規化級別較高的時候，幾乎找不到任何的冗餘資料。
盡量三正規化去除資料的冗餘，讓我們查詢相同的資料量的時候能夠多返回幾條記錄，還有乙個很重要的原因就是在當時的那個年代，資料的儲存空間是及其昂貴的，而且儲存裝置的容量也都非常的小，這一點在硬體儲存裝置發展如此迅速的如今，空間大小已經不再是太大的問題了。而正規化理論中的資料一致性和使資料修改簡單保證主要是依靠添在資料庫中新增各種約束來保證，而各種約束對於資料庫來說本身其實就是乙個非常消耗資源的事情。 所以，對於基於效能的資料庫schema 設計，我們並不能完全以規範化正規化理論來作為唯一的指導。在設計過程中，應該從實際需求出發，以效能提公升為根本目標來展開設計工作，很多時候為了盡可能提高效能，我們必須做反正規化設計。
舉例：如果有兩張表：使用者表（使用者id，使用者暱稱，使用者真實姓名，使用者手機號）； 使用者繫結銀行卡表（銀行卡id，使用者id，使用者卡號，銀行類別資訊）。
現在有個需求就是使用者提現、轉賬、支付等操作。使用者提現記錄中只儲存有使用者的銀行卡id資訊，而提現需要銀行卡號、真實姓名、銀行類別。那麼首先就需要一次join查詢出需要的銀行卡資訊。
select a.realname,b.cardnum,b.bankcardname from bankcard b ,account a where a.id = b.userid ;
但是如果能在使用者銀行卡繫結表中冗餘乙個「使用者真實姓名」字段，直接一次查詢即可完成操作：
select b.realname,b.cardnum,b.bankcardname from bankcard b ;
從資料庫正規化理論來看，這樣的設計是不合理的。因為可能造成使用者 表和銀行卡表中的使用者真實姓名資料不一致。每次更新使用者真實姓名的時候，都需要更新兩個表的資料，為了盡可能讓兩者資料保證一致，應用程式中需要處理更多的邏輯。但是，從效能角度來看的話，這種冗餘是非常有價值的，雖然我們的資料更新邏輯複雜了，但是我們在考慮更新帶來的附加成本的時候，還應該考慮我們到底會有多少更新發生在使用者真實上面呢？我們需要考慮的是乙個系統的整體效能，而不是系統中單個行為的效能。就像示例中的真實姓名資料，雖然更新的成本增加了，但是查詢的效率提高了，而且發生示例中查詢的頻率要遠大於更新的頻率，通過少部分操作的成本投入換取更大的效能收穫，實際上增加乙個冗餘欄位也是值得的，有價值。
mysql三大正規化要點說明
資料庫設計正規化 關聯式資料庫中的關係必須滿足一定的要求，即滿足不同的正規化。關聯式資料庫有六種正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 巴德斯科正規化 bcnf 第四正規化 4nf 和第五正規化 5nf 滿足最低要求的正規化是第一正規化 1nf 在第一正規化的基礎上進一步...
Mysql三正規化
第一正規化 屬性不可分 第二正規化 表中的非主屬性必須完全依賴於全部主鍵，而不是部分主鍵.第三正規化 表中的非主屬性必須完全依賴於全部主鍵,而不是依賴非主鍵屬性 1 第一正規化 元組的分量不可再分 2 第二正規化 所有分量唯一決定主鍵碼，不允許部分依賴 3 第三正規化 不允許傳遞依賴。1nf,第一正...
MySql 三正規化
目錄 1.第一正規化 1nf 每一列保持原子特徵 2 第二正規化 2nf 解決方案 只要不存在復合主鍵 3 第三正規化 3nf 解決方案 實體單獨建表 正規化總結 1nf 確保每列保持原子性2nf 確保表中的每列都和主鍵相關3nf 確保每列都和主鍵列直接相關，而不是間接相關 列是基本資料項，不能在進...