前言
每天開各種會議，這不剛剛結束的組織生活會的批評環節，我又收到了一條批評，說我技術分享不多，不夠，沒有有效起到傳幫帶的作用。好吧，以後就把這些日常的傳幫帶都總結起來，發到這裏，作爲一個記錄，也以備組內小兄弟們後續翻閱查看。
這幾天在整理數據庫表的時候，看到之前的支撐方建的那些表，簡直不忍直視，完全沒有邏輯可言，反正就是一堆東西都放到一個表裏，不知道大學數據庫理論是怎麼學習的。今天在和組內小兄弟們溝通時，就說起這個東西，正好涉及到數據庫的三範式，就順帶總結下來。
數據庫三範式
這個東西是一種關係型數據庫設計理論理論原則，也不是說必須去遵守，只是說我們在進行數據庫建模時，按着這個理論來執行，會更科學一點，會更合理一點，後續擴展性會更強一點；並且能在很大程度上消除數據冗餘和數據依賴性，提高數據庫的性能和數據一致性。
所以，這套理論有這種那種的優點，我們在進行關係型數據庫建模時，也基本都是按照這個理論來執行的，至少按照這個來，做出來的東西不會太差。
三範式的定義：
第一範式（1NF）：確保數據庫中的每個列都是原子性的，即每個列都不可再分。
第二範式（2NF）：在滿足第一範式的基礎上，確保數據庫中的每個非主鍵列完全依賴於主鍵。
第三範式（3NF）：在滿足第二範式的基礎上，確保數據庫中的每個非主鍵列都不傳遞依賴於主鍵。
以上是三範式的定義，可能不是很好理解，下面通過具體的數據庫建模實例來進行說明。
第一範式（1NF）
第一範式（1NF）要求的是列的原子性。這樣講可能不太好理解，現在有下面這樣的一個地址表：
結合第一範式（1NF）的定義，很顯然，地址詳情這列包含的信息量很大，顯然是可以拆分的。按照第一範式（1NF），我們進行以下拆分：
這樣拆分完，每個列都無法進行再次拆分了，同時使得數據庫結構更加清晰和易於維護，也有利於後期的運營分析。
第二範式（2NF）
第二範式（2NF）要求每個非主鍵列只依賴於主鍵而不依賴於其他非主鍵列，具體的應用場景是聯合主鍵（多個字段共同充當表的主鍵），這裏通過以下例子來進行說明（訂單編號和產品編碼組成聯合主鍵）：
直接看感覺沒有什麼毛病，但是我們來對上表的字段進行分析：
購買價格：購買價格完全依賴訂單編號+產品編號，訂單編號+產品編號同時確定才能確定購買價格（同一產品在不同的訂單會有不同的價格）；
購買數量：購買數量完全依賴訂單編號+產品編號；訂單編號+產品編號同時確定才能確定購買數量；
訂單總金額：訂單總金額只依賴於訂單編號，和實際的產品沒有關係，我們通過訂單編號就可以明確訂單總金額；所以該字段違背了第二範式（2NF）；
購買時間：購買時間只依賴於訂單編號，一個訂單的所有商品肯定是同一時間購買的，該字段很明顯和產品編號是無任何依賴關係的；所以該字段也違背了第二範式（2NF）。
現在我們進行優化，進行表拆分，拆分後得到兩個表：
這樣拆分完後，就符合了第二範式（2NF），同時數據結構更加清晰，也減少了數據冗餘。
第三範式（3NF）
第三範式（3NF）說直白點就是表中的非主鍵字段和主鍵字段直接相關，不允許間接相關。下面通過一個表來進行說明（主鍵：部門ID）。
很明顯，部門名稱和負責人和部門ID是直接關聯了，而負責人性別和負責人年齡和部門ID並沒有直接關係，而是和負責人直接關聯的，所以就存在這種傳遞依賴關係了。
部門ID->負責人->負責人性別
部門ID->負責人->負責人年齡
這就違反了第三範式（3NF），這個時候就需要把上表拆分成兩張表，以外鍵形式關聯。如下所示：
這樣拆分後，結構立馬清晰了，每個表存儲的數據也都是單一的。
總結
在日常開發中，我們少不了進行功能模塊的數據庫建模，而數據庫三範式是設計數據庫表結構的規則約束，通過遵循三範式，可以減少數據冗餘、提高數據的一致性和準確性，並且簡化數據庫的設計和維護。
但是通過上面的分析，我們遵循了三範式，就會多了好幾張表，導致在一些業務複雜的場景，就會出現多表關聯查詢效率低的問題。所以，有的時候進行系統性能優化時，也會打破三範式規則，進行局部變通，做到根據具體業務場景活學活用。
但凡事都有一個但是，但是在實際開發中允許局部變通。