關於範式的一些簡單理解

---恢復內容開始---

數據庫範式（Normal forms）：是用於規範關係型數據庫設計，以減小謬誤發生的一種準則。

儘管有不少概念定義性的東西，可是在實際使用數據庫的過程當中仍然有不少不盡人意的地方，下面我經過一些實例和圖片簡要分析一下範式的特色，也是我對範式的一下我的的理解。本篇隨筆咱們主要經過第一範式（1nf）,第二範式（2nf）,第三範式（3nf）和bcnf範式，其中咱們重點關注的就是第一範式。

第一範式，第一範式是關係型數據庫的基礎條件，我將1nf的特色概括爲如下幾點：

      1.不容許出現重複的行；

      2.沒有重複的列；

      3. 每列(或者每一個屬性)都是不可再分的最小數據單元，即符合原子性；

 舉例說明：列值中含有分隔符或者屬性字符串意義相同。

                       

不難發現第一個圖中愛好這一列能夠分解爲兩列，如右圖中所示，可是這樣就不符合1nf要求的列不可再分的要求，右圖也不符合沒有重複列的要求，不符合1nf。

符合第一範式應該以下圖所示（同時去掉第一個表的愛好字段）：

那麼符合第一範式帶來的好處：減小了代碼的繁瑣（好比Substring等的頻繁使用），提升了查詢的效率，方便使用關鍵字搜索，提升了數據庫的性能。

第二範式，2nf依賴1nf，因此2nf必須符合1nf，而後第二範式須要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。

舉例說明：

如圖所示，咱們將Name和City兩個屬性做爲主鍵，省份這個字段依賴於城市這個字段,同時不依賴於Name這個字段，根據城市能夠肯定省份。省份跟Name沒有關係不符合第二範式。

應該將省市單獨拿出來獨立成表（AddressID,Province,City）,主表則變成（ID,Name,AddressID），經過AddressID關聯。解決了可能存在的數據冗餘、插入、刪除和更新異常。

第三範式,消除對主鍵的傳遞依賴,簡而言之，第三範式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。

下面我直接給你們看一個正確的第三範式的例子：

所謂傳遞依賴就是這樣的邏輯：訂單編號-》客戶編號-》客戶名稱...這樣的依賴不該該在一個表裏面(主鍵是訂單編號)，如圖，客戶名稱、所屬公司、聯繫方式，依賴於客戶編號，分解成兩個表之後消除了非主鍵的傳遞依賴。

BCNF(Boyce-Codd normal form)，在3NF的基礎上，表中任何字段對任一候選關鍵字段的傳遞函數依賴都不存在。

定義：任何F可推導出的函數依賴X->A都在T中，這裏A是不在X中的單一屬性，X必須是T的一個超鍵。當一個數據庫模式包含的全部表都符合BCNF時，這個數據庫被稱爲符合BCNF.---這東西實在是太晦澀了。

個人理解：它要求關係模型中全部的屬性（包括主屬性和非主屬性）都不傳遞依賴於任何候選關鍵字。也就是說，當關系型表中功能上互相依賴的那些列的每一列都是一個候選關鍵字時候。

UserID    Name    ProductID          UserEmail         ProducName

1                tom             1               ttt@sina.com       box

首先拆分紅兩個表

UserID    Name    UserEmail        

1            tom     ttt@sina.com

 ProductID          ProducName

1                          box

這樣沒有任何主屬性和非主屬性的傳遞依賴了，可是缺乏的是UserID 和ProductID的關係，咱們還要加入關係表

UserID   ProductID

    1            1

總結：就關係數據庫而言，從其餘元素中消除數據冗餘問題，去除重複每每以減小冗餘, 從特定的表中最小化冗餘意味着擺脫沒必要要的數據。 在商業環境中，絕大多數超越第3範式的設計都是不切實際的。 由範式的進階來看，越高等級的範式所產生的表越多，而在應用程序使用的過程當中越多的表Join和查詢形成的性能損耗的問題，甚至不少狀況下爲了兼顧性能和開發咱們甚至要作一下反範式的操做，這個我準備接下來單獨說一下。

      通常認爲超過第三範式都是多餘的，因此再實際工做中不能太過教條，這裏討論更可能是理解概念的一些討論，經過總結以上這些概念幫助咱們更好的設計，可是隻有按照實際需求來設計纔是王道。哈哈