數據庫規範化

如果有人可以指導我幫助我了解我的結果是否正確，我將不勝感激。假設我有下表：

BOOK (BookTitle, AuthorName, BookType, ListPrice, AuthorAffil, Publisher)

AuthorAffil指作者所屬單位。假設存在以下函式依賴：

{BookTitle} -> {Publisher, BookType} 
{BookType} -> {ListPrice} 
{AuthorName} -> {AuthorAffil} 

有人問我這個表是 1NF、2NF 還是 3NF。

我相信這個表在 1NF 中，因為沒有兩行數據包含重複資訊。

如果這是一個 2NF，它必須看起來像：

R1 = {BookTitle} -> {Publisher, BookType, ListPrice} 
R2 = {AuthorName} -> {AuthorAffil} 
R3 = {AuthorName, BookTitle} -> {extras} 

我想知道我是否理解這個概念或者是否有任何錯誤。歡迎任何類型的幫助。

讓我們區分第一範式和第二範式。

第一範式 (1NF)

您不能說一個表是否在 1NF 中，因為沒有兩行包含重複資訊。通過重複資訊，您可能會認為BOOK看起來不像這樣：

BOOK { BookTitle, AuthorName1, AuthorName2, AuthorName3, BookType, ListPrice, AuthorAffil, BookPublisher  }

這真的不是 1NF 的定義。相反，只有當每一行中的每一列都具有為該列定義的任何類型的單個值（無論多麼複雜）時， BOOK才屬於 1NF。雖然添加多個AuthorNames列可能是糟糕的設計，但它並不違反 1NF，因為每個列都包含單個作者的姓名。現在違反1NF 的是，如果我們有一個AuthorNames列並將其定義為包含一個逗號分隔的作者姓名列表。在那種情況下，我們絕對知道BOOK不在 1NF 中。

也有可能我們將表變數設計為 1NF，假設只有一個作者姓名會被放入AuthorName列，但我們的使用者開始放入逗號分隔的作者列表。現在生成的表不在1NF 中，即使我們的意思是這樣。在這兩種情況下，表甚至不再是關係表，因為它不再遵循獲得關係屬性所必需的規則。

其次，如果不存在至少一個候選鍵，您就不能說BOOK是否在 1NF 中！如前所述，BOOK沒有候選鍵，因此允許為兩行或多行中的每一列輸入相同的值。這將導致重複行，並且具有重複行的表不是關係表！

第二範式 (2NF)

從嘗試將BOOK分解為****BookTitle的候選鍵看來，假定為AuthorName。即使這個假設是正確的，說原始表現在是 2NF 也是不正確的。相反，在分解產生的 3 個表中，現在必鬚根據功能依賴關係對每個表進行評估。 R2在 5NF 中，因為它的單個非鍵列完全依賴於鍵，並且該鍵是唯一的候選鍵並且它是單個列。 R3在 5NF 中，因為它唯一的非鍵列（假定的“附加”）在功能上也完全依賴於單個候選鍵，並且沒有額外的候選鍵。只有R1現在是 2NF 但不是 3NF，因為它有一個非鍵列ListPrice，它在功能上依賴於另一個非鍵列BookType，因此形成了傳遞依賴。

BookTitle、AuthorName的單個候選鍵的假設也可能不正確！也許在這個特定的圖書世界中，每一本書都只有一位作者。如果是這種情況，那麼R3的創建相對於實際的功能依賴是不正確的。因此，與主題專家一起澄清所有候選鍵和所有功能依賴關係、連接依賴關係和多值依賴關係並且永遠不要假設它們是至關重要的。否則錯誤的設計結果。假設每本書有很多作者，而實際上每本書只能有一個作者導致R3允許BookTitle的 FD –>AuthorName被違反。假設每本書有一個作者，而實際上每本書可能有很多作者，結果會產生一個類似於原始BOOK的表格，使用者發現他們只有一個作者姓名的空間，而不是他們需要的作者姓名，他們發現他們唯一的選擇是輸入集合作者姓名，由逗號或豎線等分隔。

參考

Fabian Pascal 的實用數據庫基礎系列和 CJ Date 的電腦專業人員關係理論是了解什麼使表成為關係表和規範化基礎的極好參考。正是從這些來源得出了此答案中的所有資訊。

定義鍵

第一步是定義密鑰。假設不能存在兩本同名的書，關鍵是BookTitle。

正常化

1NF 如果我們假設一本書有一個作者，我們可以認為關係在 1NF 中。例如，我們不會有

          BookTitle                               AuthorName
Data Structures & Other Objects Using C++     Michael Main, Walter J. Savitch

但我們會有

    BookTitle                                    AuthorName
Java: A Beginner's Guide                           Herbert Schildt

我們可以這樣想，因為我們有“AuthorName”而不是“Authorsnames”或其他。

2NF如果 {BookTitle} 是鍵，則關係肯定在 2NF 中，因為每個鍵的鍵僅由一個屬性組成

3NF我們必須考慮每一個傳遞函式依賴。

他們是：

{BookType} --> {ListPrice} 
{AuthorName} --> {AuthorAffil} 

所以 3NF 正規化是：

Books {BookTitle (key), AuthorName (fk: Authors), Booktype (fk:BookTypes),Publisher)
Authors {AuthorName (key), AuthorAffil}
BookTypes {BookType (key), ListPrice}

其中 fk 表示另一個表的外鍵

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