數據庫範式

3.1 數據庫規範化

範式是關係數據模型中關係的一種屬性，它在冗餘方面對其進行了表徵，可能導致採樣或更改數據的邏輯錯誤結果。範式被定義為關係（數據庫中的表）必須滿足的一組要求。

將數據庫關係轉換為符合規範形式的形式的過程稱為規範化。規範化旨在使數據庫的結構成為提供最小邏輯冗餘的形式，而不是為了降低或提高性能，或者減少或增加數據庫的物理量。

規範化的最終目標是減少存儲在數據庫中的信息的潛在不一致性。歸一化過程的一般目的如下：

• 排除某些類型的冗餘；
• 修復一些更新異常；
• 開發一個足夠“高質量”地表示現實世界的數據庫項目，直觀且可以作為後續擴展的良好基礎；
• 簡化應用必要完整性約束的程序。

冗餘通常通過分解關係來消除，分解關係的方式是在每個關係中只存儲主要事實（即，不是從其他存儲的事實派生的事實）。

雖然規範化思想對數據庫設計非常有用，但它們絕不是提高數據庫設計質量的通用或詳盡手段。這是因為數據庫結構中可能存在的錯誤和缺陷種類太多，無法通過規範化消除。

儘管有這些考慮，歸一化理論是關係理論和實踐的一項非常有價值的成就，因為它為數據庫項目的質量提供了科學上嚴格和合理的標準，並提供了提高這種質量的形式化方法。這使得歸一化理論從其他數據模型中提供的純經驗設計方法中脫穎而出。此外，可以說，在整個信息技術領域中，在形式嚴謹性方面，幾乎沒有一種方法可以與關係數據庫規範化理論相媲美，用於評估和改進設計方案。

規範化有時會受到批評，理由是“這只是常識”，任何有能力的專業人員都會“自然地”設計一個完全規範化的數據庫，而不必應用依賴理論。

然而，正如Christopher Date教授所指出的，歸一化恰恰是指導成熟設計師心目中的常識性原則，即歸一化原則是形式化的常識。同時，識別和形式化常識原則是一項非常艱鉅的任務，成功解決它是一項重大成就。

3.2 第一範式

第一範式（1NF）是關係數據模型中關係的基本範式。

當且僅當在該變量的任何有效值中，每個關係元組的每個屬性都恰好包含一個值時，關係變量才處於第一範式。

在關係模型中，根據關係概念的定義，關係始終處於第一範式。

至於各種表，它們可能不是關係的正確表示，因此可能不在 1NF 中。根據 Christopher Date 對這種情況的定義，當且僅當它是某種關係的直接和真實表示時，表格才被規範化（等效地，處於第一範式）。更具體地說，有問題的表必須滿足以下五個條件：

• 行沒有從上到下的順序（換句話說，行的順序不傳達任何信息）。
• 列沒有從左到右的順序（換句話說，列的順序不包含任何信息）。
• 沒有重複的行。
• 一行和一列的每個交叉點只包含來自相應域的一個值（沒有別的）。
• 所有列都是“常規”的。

表的所​​有列的“規律性”意味著表中沒有“隱藏”的組件只能在調用某些特殊運算符而不是引用常規列名時訪問，或者導致行的副作用或調用標準運算符時的表。

原始的非規範化（即不是某種關係的正確表示）表：

簡化為 1NF 的表格，這是某些關係的正確表示：

3.3 第二範式

當且僅當關係變量處於第一範式並且每個非鍵屬性都不可約地依賴於（每個）其候選鍵時，關係變量才處於第二範式。

不可約性意味著潛在的鍵不包含更小的屬性子集，從中也可以派生出這種功能依賴性。對於不可簡化的功能依賴，通常使用“完全功能依賴”的等價概念。

如果候選鍵很簡單，即它由單個屬性組成，那麼對它的任何功能依賴都是不可減少的（完全的）。如果候選鍵是複合鍵，則根據第二範式的定義，關係中一定沒有非鍵屬性依賴於復合候選鍵的一部分。

將關係轉換為第二範式的示例

讓一對屬性 {Company branch, Position} 形成以下關係中的主鍵：

假設薪水取決於部門和職位，而計算機的可用性僅取決於職位。

存在函數依賴 Position -> Having a computer，其中左邊（行列式）只是主鍵的一部分，違反了第二範式的條件。

為了減少到 2NF，原始關係應該分解為兩個關係：

3.4 第三範式（3NF）

當且僅當以下條件為真時，關係變量 R 在 3NF 中：

• R是第二範式。
• 沒有非關鍵屬性R不依賴於候選鍵的傳遞函數R.

定義說明：

關係 R 的非鍵屬性是不屬於 R 的任何候選鍵的屬性。

屬性集 Z 對屬性集 X（寫作 X → Z，發音為“x 決定 z”）的函數依賴是傳遞的，如果存在這樣的一組屬性 Y，即 X → Y 和 Y → Z。在這個在這種情況下，集合 X、Y 和 Z 都不是另一個集合的子集，即函數依賴 X → Z、X → Y 和 Y → Z 不是微不足道的，並且也不存在函數依賴 Y → X。

3NF 的定義等同於 Codd 的定義，但措辭不同，由 Carlo Zaniolo 在 1982 年給出。根據它，一個關係變量在 3NF 中當且僅當它的每個函數依賴 X → A 至少滿足以下條件之一：

• X 包含 A（即 X → A 是平凡的函數依賴）
• X - 超級鍵
• A 是鍵屬性（即，A 是候選鍵的一部分）。

Zaniolo 的定義清楚地定義了 3NF 和更嚴格的 Boyce-Codd Normal Form (BCNF) 之間的區別：BCNF 排除了第三個條件（“A 是關鍵屬性”）。

Bill Kent 給出了 Codd 的 3NF 定義的一個令人難忘的傳統描述性摘要：每個非鍵屬性“應該提供關於鍵、完整鍵的信息，並且除了鍵之外別無其他”。

依賴非鍵屬性“全鍵”的條件保證了關係是第二範式；而他們“只依賴鑰匙”的條件是他們處於第三範式。

Chris Date 將 Kent 的總結稱為 3NF 的一個“直觀吸引人的特徵”，並觀察到，稍作修改，它也可以作為更嚴格的 Boyce-Codd 範式的定義：“每個屬性必須提供關於密鑰的信息，一個完整的密鑰，除了密鑰之外什麼都沒有。

Kent 版本的 3NF 定義不如 Data 公式的 Boyce-Codd 範式版本嚴格，因為前者僅聲明非鍵屬性依賴於鍵。

主要屬性（是鍵或它們的一部分）根本不需要在功能上依賴；他們每個人都通過提供密鑰本身或其中的一部分來提供有關密鑰的信息。此處應注意，此規則僅對非鍵屬性有效，因為將其應用於所有屬性將完全禁用所有復雜的替代鍵，因為此類鍵的每個元素都將違反“完整鍵”條件。

以關係變量 R1 為例：

每個員工只屬於一個部門；每個部門都有一部電話。Employee 屬性是主鍵。員工沒有私人電話，員工的電話號碼完全取決於部門。

在示例中，存在以下功能依賴項：Employee → Department、Department → Phone、Employee → Phone。

關係變量 R1 處於第二範式，因為每個屬性都對潛在鍵 Employee 具有不可簡化的函數依賴性。

關係 Employee → Phone 是可傳遞的，因此該關係不符合第三範式。

拆分 R1 會產生兩個符合 3NF 的關係變量：

如果需要，初始關係 R1 很容易作為連接關係 R2 和 R3 的操作的結果獲得。