如何辨識功能依賴關係並根據屬性規範化表？

我無法辨識構成特定表的功能依賴關係（FD）的屬性組合。雖然我了解在給定 FD 時規範化過程是如何工作的，但我無法翻譯和辨識給定表的 FD。

我的任務是創建一家公司的數據庫，用於跟踪銷售/包裹等的所有費用。這自然意味著為公司儲存客戶資訊以辨識所有消費者。

CREATE TABLE Customers (
   id        integer primary key,
   address   text not null,
   name      text not null,
   email     text unique not null,
   phone     text unique not null,
   unique(name, address)
);
   

鑑於每個電話號碼和電子郵件都與客戶唯一關聯，因此我選擇代表客戶表的資訊。唯一約束允許來自同一家庭地址的多個人出現在表中。

我想看看我是否可以進一步規範化這個表，但是我無法辨識屬性來確定所需的 FD。

當且僅當 Y 由 X唯一確定時，一組屬性 Y 在功能上依賴於另一組 X ，也就是說，您不能將兩個不同的 Y 值關聯到相同的 X 值。因此，例如，假設一個電話number 始終只與一個人相關聯，並且一個人始終只有一個地址，您可以說函式依賴phone -> address成立，因為給定某個電話號碼，只有具有該號碼的人的地址才能與其一起出現.

因此，函式依賴以正式的方式指定了在您的數據庫中建模的現實的一個重要事實。

函式依賴的一個問題是你可以有很多，即使是小的關係。解決這個問題的一個聰明方法是只定義一小組依賴關係，足以“擷取”關於某個現實的所有基本資訊，因為我們可以以機械的方式從這個集合中導出所有其他依賴關係（並且有可以做到這一點的程序，例如通過應用著名的“阿姆斯特朗公理”）。然而，有時定義這樣的“基本”函式依賴集並不容易，我們必須仔細查看我們正在建模的問題的規範。

通常我們從所謂的“候選鍵”開始，即在關係中“自然”唯一的屬性或屬性集。由於它們是獨一無二的，我們知道它們決定了所有其他屬性。在您的範例中，您已經確定了四個候選鍵，id（主鍵）(name, address)、phone和email（已聲明unique），所以我們已經可以這樣說：

id -> name, address, email, phone
name, address -> id
phone -> id
email -> id

（注意，說一個屬性決定了一個候選鍵就足夠了，因為從這個事實我們可以得出它決定了所有其他屬性，即它唯一地決定了一個人）。

然後我們可以查看屬性組合中的某個其他屬性是否唯一確定了其他屬性或候選鍵（相當於確定了所有其他屬性）。

您的關係中還有其他（非平凡的、有趣的）函式依賴關係嗎？可能不是，考慮到數據的明顯語義（例如，兩個不同的人可以有相同的地址，所以一個地址不能“唯一確定”任何東西，或者兩個不同的人可以有相同的名字，等等）。因此，我們可以有一定程度的信心，這四個 FD 是 FD 的“基本”集合（從技術上講，這稱為關係的 FD 集合的“覆蓋”）。

所以從這個封面我們可以開始規範化關係（在這種情況下已經規範化了）。

引用自：https://dba.stackexchange.com/questions/289717