設計關系數據庫的一個重要部分是將數據元素劃分為相關的表。一旦準備好開始處理數據，就可以依賴表之間的關系以有意義的方式將數據聚合在一起。例如，除非您知道哪個客戶下了特定的訂單，否則訂單信息是無用的。到目前為止，您可能已經意識到，您並沒有將客戶和訂單信息存儲在同一個表中。而是將訂單和客戶數據存儲在兩個相關表中，然後使用這兩個表之間的關系同時查看每個訂單及其相應的客戶信息。如果規範化表是關系數據庫的基礎，那麽關系就是基礎。

　　本文使用以下數據進行演示。通過Boyce - Codd範式( BCNF )對數據進行規範化的過程產生了七個相關表格:
　　書籍: {標題*，ISBN，價格}
　　作者: {名字*，姓氏* }
　　郵政編碼: {郵政編碼* }
　　類別: {類別*，說明}
　　發布者: {發布者* }
　　狀態: { State * }
　　城市: {城市* }

關系類型
你和家人有很多關系。例如，你和你母親是親戚。你只有一個母親，但她可能有幾個孩子。你和你的兄弟姐妹是親戚——你可能有很多兄弟姐妹，當然，他們也會有很多兄弟姐妹。如果你結婚了，你和你的配偶都有配偶——彼此——但一次只有一個。數據庫關系非常相似，因為它們是表之間的關聯。關系有三種類型:

• 一對一:兩個表在關系的任一側只能有一條記錄。每個主鍵值僅與相關表中的一個(或否)記錄相關。他們就像夫妻一樣——你可以結婚，也可以不結婚，但是如果你結婚了，你和你的配偶只有一個配偶。大多數一對一關系都是由業務規則強制執行的，並且不會自然地從數據中流動。如果沒有這樣的規則，通常可以將這兩個表合並到一個表中，而不破壞任何規範化規則。
• 一對多:主鍵表僅包含一個與相關表中的無、一個或多個記錄相關的記錄。這種關系類似於你和父母之間的關系。你只有一個母親，但你母親可能有幾個孩子。
• 多對多:兩個表中的每個記錄都可以與另一個表中的任意數量的記錄(或沒有記錄)相關。例如，如果您有幾個兄弟姐妹，那麽您的兄弟姐妹也是如此(有許多兄弟姐妹)。多對多關系需要第三個表，稱為關聯表或鏈接表，因為關系系統不能直接容納關系。

建立關系
當您開始建立相關表之間的關系時，您可能已經非常熟悉這些數據了。因此，此時的關聯比開始時更明顯。數據庫系統依賴於在兩個表中找到的匹配值來形成關系。找到匹配項後，系統將從兩個表中提取數據以創建虛擬記錄。例如，您可能希望查看特定作者編寫的所有書籍。在這種情況下，系統將匹配圖書和作者表之間的值。重要的是要記住，大多數情況下，生成的記錄是動態的，這意味著對虛擬記錄所做的任何更改通常都將返回到底層表。

• 書籍與類別有關。
• 書籍與出版商有關。
• 書籍與作者有關。
• 作者與郵政編碼相關。
• 郵政編碼與城市相關。
• 城市與州有關。

這個特定步驟不是用石頭寫的，您可能會發現在規範化過程中添加外鍵更容易。將字段移動到新表時，可能會將新表的主鍵作為外鍵添加到原始表中。但是，在繼續規範化剩余數據時，外鍵通常會發生更改。您可能會發現，在所有表完全規範化之後，一次完成所有這些任務更有效。

讓我們從Books表開始，一次遍歷每個表，此時該表只有三個字段。具體而言，將“作者”、“類別”和“發布者”表中的主鍵添加到圖書中。完成後，“帳簿”表有七個字段:
書
標題(主鍵)
國際標準書號(主鍵)
價格
名作者。名字多對多
作者。姓多對多
類別( FK )類別。類別多對多
出版社。出版商一對多

請記住，Authors表中的主鍵是基於名字和姓氏字段的復雜鍵。因此，必須將這兩個字段添加到“帳簿”表中。請註意，外鍵字段名稱包含FK後綴。添加後綴提高了可讀性，並且是自文檔化的。如果以外鍵的名稱標識外鍵，您可能會發現跟蹤外鍵更容易。如果主鍵和外鍵的名稱不同，也沒關系。

存在三種關系:書籍與作者、書籍與類別和書籍與出版商。您可能不太清楚的是其中兩種關系的問題:

• 給作者的書:一本書可以有多個作者。
• 圖書分類:一本書可以有多個類別。

這兩種關系表示多對多關系。前面我們已經告訴過您，表不能直接適應這些關系，需要第三個鏈接表。(圖書與出版商之間的關系是一對多的關系，就像目前所說的那樣。) )

新發現的兩種多對多關系都需要一個鏈接表，其中包含每個表中的主鍵作為外鍵。新的連結資料表為:
圖書作者
書名。標題一對多
書。一對多
名作者。名字一對多
作者。姓氏一對多

圖書分類
書名。標題一對多
書。一對多
類別( FK )類別。一對多類別

不需要更改“類別”、“作者”或“發布者”表。但是，必須從帳簿中刪除名為fk、LastNameFK和CategoryFK的外鍵:
書
標題(主鍵)
國際標準書號(主鍵)
價格
出版社。出版商一對多

現在，讓我們轉到Authors表，該表當前有兩個字段。每個作者都與ZIPCodes表中的郵政編碼值相關聯。但是，每個郵政編碼可能涉及多個作者。要適應這種一對多關系，請將ZIPCodes表中的主鍵作為外鍵輸入到Authors表中:
作者
名字(主鍵)
姓氏(主鍵)
郵政編碼。郵政編碼一對多

此時，您已經準備好處理剩余的地址組件。看到它們被分成表很奇怪，但這是通過BCNF對數據進行正常化的結果。每個郵政編碼值將具有一個相應的城市和州值。每個城市和州的值將只在其相應的表中輸入一次。zipcode和城市表需要外鍵字段來適應這些關系:
郵政編碼
郵政編碼
城市。城市一對多

城市
城市(主鍵)
州。一對多狀態

州
狀態(主鍵)

從一點到九點
最後，您有九個表:圖書、作者、類別、出版商、郵政編碼、城市、州、圖書作者和圖書類別。圖一在此過程結束時，顯示示例圖書數據庫的圖形表示。很難想象一個簡單的數據表可以分成九個。

圖一

原始表現在需要九個表。

由於示例的簡單性，您可能想知道這種關系業務如何幫助您。看起來您仍然以外鍵的形式存儲冗余數據，只是不同而已。那是因為我們的表現在只有幾個字段。試著想象一張有十幾個字段的桌子。當然，您仍然必須將該表的主鍵存儲為相關表中的外鍵值，但這最多可能構成一個或兩個額外字段。與為每個記錄添加該表中的所有十幾個條目的替代方案相比。

關系數據庫:定義數據庫表之間的關系