數據庫規範化中的全功能依賴

完整的功能依賴性是數據庫規範化的狀態，等同於第二範式（2NF）的規範化標準。 簡而言之，這意味著它符合第一範式（1NF）的要求，並且所有非關鍵屬性在功能上完全依賴於主關鍵字。

這聽起來並不復雜。 讓我們更詳細地看看這個。

第一範式的總結

在數據庫完全依賴功能之前，它必須首先遵守第一範式 。

所有這一切意味著每個屬性必須保持單一的原子值。

例如，下表不符合1NF，因為員工Tina鏈接到兩個位置，兩個位置都在一個單元中：

允許此設計可能會對數據更新或條目產生負面影響。 要確保1NF合規性，請重新排列表以便所有屬性（或列單元格）具有單個值：

但是1NF還不足以避免數據問題。

2NF如何確保完全依賴

為了完全依賴，所有非候選鍵屬性必須依賴於主鍵。 （請記住， 候選鍵屬性是用於唯一標識數據庫記錄的任何鍵（例如，主鍵或外鍵）。

數據庫設計人員使用記號來描述屬性之間的依賴關係：

如果屬性A確定了B的值，我們寫這個A→B - 意味著B在功能上依賴於A.在這個關係中，A決定了B的值，而B取決於A.

例如，在以下Employee Departments表中，EmployeeID和DeptID都是候選鍵：EmployeeID是表的主鍵，而DeptID是外鍵。

任何其他屬性（在本例中為EmployeeName和DeptName）必須依賴主鍵才能獲得其值。

在這種情況下，表不完全依賴，因為當EmployeeName取決於主鍵EmployeeID時，DeptName取決於DeptID。 這被稱為部分依賴 。

為了使這個表格符合2NF，我們需要將數據分成兩個表格：

我們從Employees表中刪除DeptName屬性並創建一個新表Departments ：

現在表格之間的關係完全依賴，或者在2NF中。

為什麼完全依賴是重要的

數據庫屬性之間的完全依賴有助於確保數據完整性並避免數據異常。

例如，請考慮上面僅符合1NF的表中的表格。 這裡又是：

蒂娜有兩個記錄。 如果我們更新一個而沒有意識到有兩個，結果將是不一致的數據。

或者，如果我們想要將一名員工添加到此表中，但我們還不知道該位置？ 如果Location屬性不允許NULL值，我們可能會被禁止添加新員工。

儘管如此，在標準化方面，完全依賴並不是全貌。 您必須確保您的數據庫處於第三範式 （3NF）。