基本介紹
- 中文名：資料庫標準化
- 外文名：Database Normalization
- 定義：減少資料庫中數據冗餘的過程
- 種類：六種
範式簡介,各類範式,目的原則,反範式,
範式簡介
範式來自英文Normal form，簡稱NF。要想設計—個好的關係，必須使關係滿足一定的約束條件，此約束已經形成了規範，分成幾個等級，一級比一級要求得嚴格。滿足這些規範的資料庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、刪除(delete)和更新(update)操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
目前關係資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規範要求的稱為第二範式（2NF），其餘範式以次類推。一般來說，資料庫只需滿足第三範式(3NF）就行了。
各類範式
1、第一範式（1NF）：
所謂第一範式（1NF）是指在關係模型中，對於添加的一個規範要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重複的域。
說明：在任何一個關係資料庫中，第一範式（1NF）是對關係模式的設計基本要求，一般設計中都必須滿足第一範式（1NF）。不過有些關係模型中突破了1NF的限制，這種稱為非1NF的關係模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關係模型。
2、第二範式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函式依賴）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關係中，沒有對其身份證號進行存儲，而姓名可能會在資料庫運行的某個時間重複，無法區分出實體時，設計辟如ID等不重複的編號以實現區分，被添加的編號或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是在第一範式的基礎上屬性完全依賴於主鍵。
3、第三範式（3NF）
在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關係中不包含已在其它關係已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。
資料庫範式
資料庫範式4、巴斯-科德範式（BCNF）
Boyce-Codd Normal Form（巴斯-科德範式）
在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）
巴斯-科德範式（BCNF）是第三範式（3NF）的一個子集，即滿足巴斯-科德範式（BCNF）必須滿足第三範式（3NF）。通常情況下，巴斯-科德範式被認為沒有新的設計規範加入，只是對第二範式與第三範式中設計規範要求更強，因而被認為是修正第三範式，也就是說，它事實上是對第三範式的修正，使資料庫冗餘度更小。這也是BCNF不被稱為第四範式的原因。某些書上，根據範式要求的遞增性將其稱之為第四範式是不規範，也是更讓人不容易理解的地方。而真正的第四範式，則是在設計規範中添加了對多值及依賴的要求。
目的原則
規範化目的是使結構更合理，消除存儲異常，使數據冗餘儘量小。便於插入、刪除和更新。
遵從概念單一化“一事一地”原則，即一個關係模式描述一個實體或實體間的一種聯繫。規範的實質就是概念的單一化。
一個關係模式接著分解可以得到不同關係模式集合，也就是說分解方法不是惟一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有信息為前提來實現。其根本目標是節省存儲空問，避免數據不一致性，提高對關係的操作效率，同時滿足套用需求。實際上，並不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便數據查詢。尤其對於那些更新頻度不高，查詢頻度極高的資料庫系統更是如此。
反範式
規範化的優點是明顯的，它避免了大量的數據冗餘，節省了存儲空間，保持了數據的一致性。當一個庫里的數據經常發生變化時，達到3NF的庫可以使用戶不必在超過兩個以上的地方更改同一個值。那么是不是只要把所有的表都規範為3NF後，資料庫的設計就是最優的呢?這可不一定。範式越高意味著表的劃分更細，一個資料庫中需要的表也就越多，用戶不得不將原本相關聯的數據分攤到多個表中。當用戶同時需要這些數據時只能採用連線表的形式將數據重新合併在一起。同時把多個表聯接在一起的花費是巨大的，尤其是當需要連線的兩張或者多張表數據非常龐大的時候，表連線操作幾乎是一個噩夢，這嚴重地降低了系統運行性能。
